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.
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.
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 ()
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.
Lots were missing, and some were export, which should probably be public
export because the nature of Vect is that it could commonly be used in
types.
Fixes#13
This is part of what we used to have in Enum but I think it's better to
separate the two. Added implementations for Nat, and anything in
Integral/Ord/Neg, so that we get range syntax (at least when its
implemeted) for the most useful cases.
This required a small change to auto implicit search (and I'm still not
sure about this). Now search arguments right to left, because solving
later arguments may resolve earlier arguments by unification and this
can happen in particular when chasing parent interfaces (which may have
fewer parameters).
