For the types of local names, don't write out the environment - it's
going to be repeated for every name, mostly it's unhelpful, and if you
want to see the types of other names you can ask directly. This can save
a huge amount of time when environments are slightly complicated.
This includes: metadata collected when elaborating impossible cases,
which are just discarded whatever happens; and, types of names of global
definitions, which we can get from the context anyway. This has quite an
impact on performance, because their environment and types have to be
encoded and written out (which, by the way, we could probably do a lot
quicker by organising them by environment so we only have to write out
each environment once).
Turns out you can contrive to have buffer overruns if you use an unsafe
buffer library... oops! When resizing a buffer, we need to make sure
that the new size is enough for the thing we're about to add. This is
almost certainly the cause of #95.
If a default method implementation refers to another method in the
interface, it's going to be one from the interface being defined, so
push it through explicitly.
This is only going to be guaranteed to be the case for default method
implementations - we can't assume anything for other implementations.
Fixes#77
This makes it easier for more complicated packages (e.g. network, which
needs to install a C shared library) to know where to put things without
having to work out the prefix themselves.
This could allow us to actually erase (rather than compile with nil)
although experiments show that has no impact on performance. It is
useful to see, though, and other back ends may benefit.
Since they'll be incompatible between different Idris2 versions, this
helps protect against importing the wrong thing by mistake. Also, it
means the canonical place for the version number is now the top level
Makefile.
You'll need to delete src/YafflePaths.idr before rebuilding, since it's
now generated slightly differently.
This is so that we can put other build artefacts (e.g. executables) in
properly organised subdirectories of build, e.g. build/bin/chez,
build/bin/js, etc.
In the Chez back end, if the library spec is a name and a version
number, build an appropriate guess for the library file name based on
the system extension.
Functions can be declared as %foreign with a list of calling
conventions, which a backend will work through until it finds one it can
understand. Currently implemented only in Chez backend. If this works
out, I'll implement it for Racket too, and remove the old primitive
functions.
There's a bit more boiler plate here than before, but it has the benefit
of being more extensible and portable between different back ends.
Some examples, pending proper documentation:
%foreign "C:puts,libc" "scheme:display"
putline : String -> PrimIO ()
%foreign "C:exp, libm.so.6, math.h"
fexp : Double -> Double
%foreign "C:initscr, ncurses_glue.so, ncurses.h"
prim_initscr : PrimIO ()
On NixOS, idris2 can't find scheme in the usual locations, so it
defaults to generating the following shebang:
#!/usr/bin/env scheme --script
The `env` program interprets `scheme --script` as one monolithic
command, instead of as a command and one argument.
/usr/bin/env: ‘scheme --script’: No such file or directory
/usr/bin/env: use -[v]S to pass options in shebang lines
The -S flag forces `env` to split on whitespace in the intuitive
manner.
Since it's just to check that it's built successful and we can send a
message back and forth, remove the diagnostic message that might come
out in a different order depending on scheduling.
