I need to revisit an earlier discussion, because we made a bad decision. I
want to explain why it was a bad decision and what I now propose to do about
it.
In recent BitC, we have what feels to C programmers like an asymmetry on
type annotation. In "a:T + b", the ":T" qualifies the "a". In "a + b :T",
the ":T" qualifies the "a+b". To be clear, there is no actual asymmetry here
at all. It is merely that the C cast operator has a different precedence
than the Haskell type annotation construct. It's entirely a matter of what
is familiar.
Disliking the unfamiliarity of this, I tried to juggle the precedence of
type annotation to "fix" the issue. This had two effects:
1. It pushed me to explore a surprisingly interesting mixfix engine
design.
2. It failed to solve the problem.
The reason it failed to solve the problem is that once we introduce
type-level mixfix, it will turn out that "a:T+b" becomes ambiguous. If we
want the ability to have interesting type expressions, we need to make one
of two possible choices:
1. Move type annotation to have looser precedence than any
mixfix operation
2. Require that the type in an annotation be enclosed in parens
of some sort, e.g. expr:(type)
Either solution solves the type expression problem, but the second solution
does not solve the "feels strange to C programmers" problem.
Today it occurred to me that there is a different way to solve the "feels
strange to C" problem, which is to disallow the annotation that appears in
"a:T + b". Since that's going to become ambiguous in any case, it's probably
a good thing to remove. If we require any expression within a mixfix context
to parenthesize qualifications, that ambiguity goes away. This would leave
us writing one of:
(a:T) + b // ok - annotates a
a + (b:T) // ok - annotates b
a + b : T // ok - annotates a + b
It is now my opinion that the confusion resulting from the difference in
precedence between C cast and BitC annotation doesn't have a straightforward
resolution in the presence of type-level mixfix. Given that, the next best
solution is one that forces the programmer to be consistently explicit about
their intent. This is good both from the perspective of expressed intent an
also from the perspective of re-training programmers who may be coming from
other languages.
So my current plan is to make type annotation have loose precedence again,
and restrict the grammar in such a way that inner annotations can only
appear in bracketed contexts like parenthesis.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
