We've always said that the rules for binding names in patterns are the
same as the rules for binding names in implicits, i.e. a name beginning
with a lower case letter, not applied to anything, will be bound
implicitly, or treated as a pattern variable. This hasn't actually
always been quite true, even though it was supposed to be...
Correspondingly, added a warning for constructor names which may be
unexpectedly bound implicitly.
This patch changes the pattern binding rules so that it is the case.
Fixes#2653
Any name which would be a valid unbound implicit is now *always* an
unbound implicit. This is much more resilient to changes in inputs, but
does require that function names be explicitly qualified when in
argument position.
Updated libraries/tests accordingly.
WARNING: This is likely to break some code; the fix is, in all cases, to
give explicit namespaces for function names in types in an argument
position (i.e. a valid position for it to be an unbound implicit).
Implicit variables remain implicit in the generated case (or, more
accurately, variables which are unused in the rhs are made implicit on
the lhs), meaning that it is no longer necessary for each branch to
target the same type or for each case of the scrutinee to have the same
type.
In other words, case is now allowed provided that it does not affect the
form of any variable which is explicitly used in the case block.
Example, which is now allowed but wasn't before:
app : Vect n a -> Vect m a -> Vect (n + m) a
app xs ys = case xs of
[] => ys
(x :: xs) => x :: app xs ys
The changes are as follows:
+ `print` is for putting showable things to STDOUT.
+ `printLn` is for putting showable things to STDOUT with a new line
+ `putCharLn` for putting a single character to STDOUT, with a new line.
Effects has been updated accordingly.
Any term which is not matchable, i.e. a function application or a
repeated variable on the left hand side, is automatically put in a
PHidden. The effect of elaborating PHidden t is to:
1. Delay the elaboration of 't' to the end of elaboration
2. When elaborating t, ensure that its value is already known due to
solving some other unification problem.
If something is PHidden, but not solvable by unification, elaboration
fails.
This finally fixes#323, and probably several other things.
