On 08/14/2012 02:52 PM, Ryan Ingram wrote:
On Tue, Aug 14, 2012 at 1:04 AM, Евгений Пермяков <permea...@gmail.com
<mailto:permea...@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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
