Add "installation problem", and while I'd rather not have larger proposals on the tracker, it would still be useful to list small requests where it's objectively clear what the resolution is.
We were only checking parameters, meaning that there were potential
clashes leading to confusing behaviour, and meaning that it was somehow
relevant what the names were in the interface!
Now by marking a method as multiplicity 0, we can explicitly say that
it's compile time only, so we can use it to compute types based on other
erased things - see tests/idris2/interface008 for a small example.
This fixes#8 - at least in that it allows the interface to be expressed
properly now, although the multiplicity annotations mean that
unfortunately it can't be compatible with Idris 1.
A local variable can't be applied to itself when searching (otherwise,
for example, we could end up trying something like id id id id id id etc
forever). So remove it from the environment before searching for its
arguments.
This and the previous patch fix#24. (Or, at least, the minimised cases
reported as part of it!)
Don't use the interface itself when checking parent implementations
exist, otherwise we'll end up in a cycle (because the parent
implementation will sort of exist as a result!)
We can't begin a search until we know what we're searching for! For some
reason I forgot to add this case, and without it the search space can
explode, or we might find an answer too soon and commit to the wrong
thing!
Fixes#36
This means that even if the relevant parameters aren't used by a method
body, the method can still see what the implicits are (though they will
be 0 multiplicity).
This is relevant to #8, but doesn't really fix it because we still need
a way of saying that methods are 0 multiplicity.
We need to turn pairs into separate constraints, which is a bit of a
hack but the constraints need to be separate in order to build the
chasing functions which find the parent constraints correctly.
Possibly there is a neater way, which is to teach the search algorithm
to look in the hints for pairs, but that's a lot more complicated (and
probably unnecessarily so).
Fixes#25
This is a bit rough, but does yield an executable with a ~40% speedup in
startup latency on one test. The resulting executable is a .so file with a #!
invocation of the local chez scheme executable to run it, so the binary isn't
portable (even to a machine with the same architecture/OS) unless there's an
identical chez installation on both machines.
As with the .ss source, the .so is currently leaked in the temporary directory.
They're just about deciding whether it's okay to start an auto implicit
search, not whether it's okay to continue search, which is part of the
problem in #25.
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 hasn't been tested much (and indeed isn't in the test suite because
I haven't found the way to load shared objects nicely portably yet!) so
I hadn't noticed, but primitive types are translated to names before
compilation to support matching on types, so we need to account for
this.
Also, CG directives need to be processed after loading from ttc
A few people have reported issues that this won't build with Idris 1.3.1, which it won't. There's a note in INSTALL.md, but it's clearly not prominent enough! I will do a new release soon, but it does take time to do it properly!
We can't nest delayed elaborators (this is an efficiency constraint, to
prevent excessive searching for ambiguous names) to run elaborator
immediately if delays aren't allowed in delayElab
