[Haskell-cafe] Fixity declaration extension

[Евгений Пермяков]

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...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120814/fe639c1a/attachment.htm>