[Haskell-cafe] Fixity declaration extension
permeakra at gmail.com
Tue Aug 14 13:24:54 CEST 2012
On 08/14/2012 02:52 PM, Ryan Ingram wrote:
> On Tue, Aug 14, 2012 at 1:04 AM, Евгений Пермяков <permeakra at gmail.com
> <mailto:permeakra at gmail.com>> wrote:
> Your idea looks _much_ better from code clarity point of view, but
> it's unclear to me, how to deal with it internally and in error
> messages. I'm not a compiler guy, though.
> How to deal with it internally: It's pretty easy, actually. The
> hardest part is implementing an extensible partial order; once you
> have that and you can use it to drive comparisons, parsing is not hard.
> Basically, at each step when you read an operator token, you need to
> decide to "shift", that is, put it onto a stack of operations,
> "reduce", that is, apply the operator at the top of the stack (leaving
> the current token to check again at the next step), or give a parse
> error. The rules for deciding which of those to do are pretty simple:
Yes, I can guess it. This way. however, is linearly dependent in time
from number of operators in scope. It is clearly much worse then looking
into Map OperatorName Fixity . But changing numeric fixity in Map when
adding operator somewhere in between existing stack is also linearly -
dependent. Of course, associated penalties are small if few operators
are in scope. It is unclear for me, how heavy associated penalties will
be for both cases.
> I would expect modules to declare locally relative fixities between
> operators imported from different modules if and only if it was
> relevant to that module's implementation.
Noway. Monoid, Monad and Functor are absolutely independent typeclasses
and defined in different modules. There is, however, type , which has
instances for all three typeclasses, so operators for all three of them
have to play together. Thus, when you create typeclass and
operator-combinators for it, you should add them to entire set of
operators on all hackages, as you never know, which typeclass instances
will give some yet unknown types. So, rules for such cases must exists,
and leaving priorities undefined is not a good way.
> In most cases I expect the non-ordering to be resolved by adding
> parentheses, not by declaring additional precedence directives; for
> example, even though (a == b == c) would be a parse error due to ==
> being non-associative, both ((a == b) == c) and (a == (b == c)) are
> not. The same method of 'just add parentheses where you mean it'
> fixes any parse error due to incomparable precedences.
I hate lisp-like syntax.
> -- ryan
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe