If there's a conversion failure in unification, there could still be a
way to rescue it if one of the terms is a lazy type, so postpone rather
than giving up. Fixes#225
For example, delayed elaborators. If it resolves one, and it's not a
complete solution, we might end up with unsolved holes. Or - possibly
worse - we might end up with an error in a program that is silently
fixed rather than reported!
Fixes#223
If there's a 'case' with multiple branches, some of which have holes, we
don't know what the effect on the usage should be, so leave it alone and
just update the hole types. It's get fully checked when all the holes
are resolved.
Most importantly: Case operators should not be inlined indiscriminately,
because that might duplicate work (e.g. via a variable pattern for the
scrutinee, where the variable is used more than once)
This is needed to get the time correctly on 32 bit systems (for example,
a Raspberry Pi!) otherwise it reports a negative number for the current
time...
This has two main advantages: firstly, it actually makes the build slightly
faster and less memory intensive, because Idris doesn't fork a new
process and eat all the memory! Secondly, it means we can build a
distribution with the C file, for building on machines which don't have
Idris 1 available.
Also includes a script for building such a distribution.
I expect someone who is better a writing Makefiles than me can tidy this
up. There are almost certainly problems on Windows too - please help if
you can!
There are new Make targets 'all-fromc' and 'install-fromc' which don't
require building from Idris source, so that we can build with no Idris 1
available.
A small consequence: make install-exec no longer builds the idris2
executable, just installs it.
Explaining how to write the most basic Idris bindings for readline,
taking account of how to allocate Strings in the completion callback.
Also adds the basic API as a sample, which can be used as a starting
point for other packages containing C bindings.
For an output file 'f', now generate a subdirectory in the executable
directory 'f_app', and put 'f.so' and 'f.ss' in there, along with any C
libraries we might have needed. Then generate a shell script 'f' to set
the library path to `f_app` and invoke `f.so`.
In :exec mode, f = _tmpchez, so we're using the executable directory for
the temporary files.
This means all the libraries and code needed to run the generated
program are copied to a single relocatable target directory.
This almost certainly won't work on Windows. Please help! Thanks :)
