Damian, Moritz, etc,
It seems to me that the basic problem here is that the vertical bar | has 2
different meanings (outside rules) depending on context.
When used with type names it produces a union type, while with normal values
such as integer literals it produces a junction value.
Routine signatures are actually looking for type names/definitions, but we allow
single values eg 1 as a shorthand for "Int where 1", the type is from the type
of the value, and so 0|1 would naturally turn into Junction-where.
I believe that the current behavior is correct given that. If it can't find
full syntax for a type name or type definition, then it takes what was found as
a shorthand for a generic value expression, in which case 0|1 is interpreted
same as it would in any value expression.
And if we want 0|1 to be treated differently we need to do it in terms of a
consistent change to how places expecting type names/defs are parsed.
For example, if we see a | and we don't see a "where" we treat each side still
according to type-def rules, in this case Int-where|Int-where, and only if we
can't do that, then look at the whole thing as a single value expression.
One can also force the as-value-expression interpretation of | by having an
explicit 'where' or something.
-- Darren Duncan
On 2014-03-18, 3:26 AM, Damian Conway wrote:
As I read the specs,
multi fib(0|1) { 1 }
would be short for
multi fib(Junction $ where 0|1) { 1 }
which I believe doesn't do what you want.
Ah, yes, that's certainly consistent.
Though not, perhaps, very useful.
So maybe it's better that it doesn't compile at all. ;-)
I guess I could (eventually) use:
multi fib(Int where 0|1) { 1 }
and this *does* work currently:
multi fib(Int $ where 0|1) { 1 }
Thanks,
Damian
