These can give valuable information, but since they're not well typed,
we have to rebuild as close an approximation as we can before passing it
to the case tree compiler. We can do this in a type-directed way, but
ignoring whether any of the arguments are convertible, and not trying to
solve any of the implicits. If this fails, it doesn't use the impossible
case, otherwise it uses it to find the missing cases in the resulting
case tree.
If the name is given (rather than, say, computed) update it so that it's
the data type name being defined - so ambiguities are resolved
immediately. Fixes#192
Pass through the types of the interface parameters to the top level
method types, because there might be information in there that we can't
otherwise infer. Fixes#188
This means we can say 'let x = foo' and have foo not be applied to its
implicit arguments, meaning that 'x' can be instantiated at whatever
implicits it needs through the scope.
It doesn't achieve anything useful, and can be confusing because it
means behaviour is different for names where ambiguity is pruned by type
vs names where it isn't.
If a let binding doesn't elaborate with a 'precise' inference, revert to
generalising. I still don't like this - we really need to be able to
postpone choice of multiplicities during unification. But we can't, yet,
so here we go.
We've been generalising inferred function types to have multiplicity
RigW but sometimes (especially on lambdas) we need to infer the precise
type, so make a distinction.
This is pretty ugly, really. It would be better to be able to postpone
the choice until we know more, but it's not obvious to me how to achieve
that with the way unification is currently set up. The present way at
least works fine with code that doesn't use linearity, which is the
right default I think!
Now only abstracts over the environment once and deals with 'where'
clauses by rewriting the nested name with the rearranged environment. As
a result, it interacts far better with local definitions (i.e. where
blocks).
They're global, and so we don't reset per file, so we might get
duplicates, so it's much quicker to store as a map even though we'd
expect few of them overall.
The Chicken backend and reflection code are currently unused, and add to
memory usage and build time, so best leave them out for the moment.
They will be back! But probably best to wait until we can self host -
which hopefully won't be long - and we can take advantage of some of
the things Idris 2 does to compile quicker and using less space!
This is the same as %auto_implicits in Idris 1, but with a more
appropriate name, because auto implicits are something else.
'%unbound_implicits off' turns off implicit forall bindings. See test
basic033 for an example.
Need to use 'check' which expands ambiguous names, rather than
'checkImp' which does nothing. It won't insert any new dots since it
checks in expression context.
It's a big patch, but the summary is that it's okay to use a pattern in
an erased position if either:
- the pattern can also be solved by unification (this is the same as
'dot patterns' for matching on non-constructor forms)
- the argument position is detaggable w.r.t. non-erased arguments, which
means we can tell which pattern it is without pattern matching
The second case, in particular, means we can still pattern match on
proof terms which turn out to be irrelevant, especially Refl.
Fixes#178
Rather than just raw Strings. They get evaluated immediately at the
point of elaboration, and this can be used to save repetition (e.g. of
shared library names) in declarations.
To build the top level method and interface record correctly, we need to
know where to put the implicit arguments, so invent names if they don't
have them already then we'll know where to put things accurately.
Earlier solutions may influence later ones. Probably we should be
cleverer still here, and keep trying while any delayed elaborators are
run successfully, because really the order shouldn't matter!
In the case where the function type is not yet known, and there's a
postponed unification problem, we were returning the function type not
the result type.
--debug-elab-check ought to be extended to catch this sort of thing.
Fixes#168
