[bitc-dev] Does MixFix require arity-free procedures?
Jonathan S. Shapiro
shap at eros-os.org
Sat Sep 4 21:01:47 PDT 2010
I just hit a bit of a snag. I have most of a mixfix implementation done, and
I got hung up on the following input:
def _**_(a, b) = if b == 0 then 1 else a * (a ** (b - 1))
Once mixfix is implemented, things like "*" and "**" are just identifiers
followed by an open parenthesis, so the parser treats them as a procedure
1. Treat all procedures as arity-1, adopting the view that when a procedure
is applied to an argument having tuple type we apply the native calling
convention to the elements of the tuple (as previously discussed).
2. Adopt the view that a mixfix introduction changes the behavior of the *
token*, in that the parser immediately updates the state of the lexer to
advise it that new quasi-keywords have been bound in the current context.
This causes precedence to be bound on the token rather than the entity, and
therefore deviates from the Haskell specification significantly. I don't
feel like I have an intuition about how bad a thing that would be.
We can't defer application processing into the mixfix layer, because by that
point the parenthesis that were used syntactically to signal the presence of
application are long gone.
Before I make a mess that might be hard to back out of, can somebody explain
whether/why the entity/name distinction is important in Haskell mixfix? My
hope is that the ability to do a wholesale replacement on the current syntax
table provides a satisfactory alternative.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev