Proposal: change to qualified operator syntax

[John Launchbury]

Simon,

Thanks for summarizing the arguments about qualified operators. I  
continue to be a strong advocate of this approach. IMO, we either have  
to do this, or disallow . (dot) as an operator, and I think you are  
right that it is too late to do the latter.

In the proposed implementation of this change, you say:

> Prelude.(>>=) has to be a single lexeme, because there's no way to  
> lift the syntax of qualified names into the context-free grammar. So  
> this forces us to move the syntax for parenthesized operators and  
> `..` down to the lexical syntax

with the consequent behavior that `---` and (---) are not dual.

Can you regain duality by *also* providing a definition of `---` and  
(---) at the level of the context free grammar?

John


John Launchbury   | galois |   (503)626-6616 x104


On Jul 9, 2009, at 4:22 AM, Simon Marlow wrote:

> On 08/07/2009 23:06, kahl at cas.mcmaster.ca wrote:
>> Simon Marlow replied to Henning Thielemann:
>>
>>  >  Prelude.>>= just doesn't look like an infix operator.  The  
>> point of
>>  >  infix operators is that they are a lightweight notation, but  
>> they lose
>>  >  that advantage when qualified.  The qualified operator proposal  
>> gives
>>  >  you a nice rule of thumb to rely on when parsing code in your  
>> head: if
>>  >  it begins with a letter, it is not infix.  The advantages of this
>>  >  shouldn't be underestimated, IMO.
>>
>> Actually, I am another supporter of qualified infix operators.
>>
>> Is see on
>>
>>  >  http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
>>
>> that with the new proposal, I would have to write
>>
>>   `Prelude.(>>=)`
>
> You don't *have* to write that, you can use the prefix form.  The  
> argument that this proposal makes is that when you have to qualify  
> an operator, it has lost most of the advantages of being infix.
>
>> . I frequently run into situations where that would be extremely  
>> useful.
>>
>>
>>  >   the M.. M... M.... debacle
>>
>> I don't think that problems arising from a single character
>> should outlaw a whole lexical category.
>> Better outlaw that character! ;-)
>
> Dot is a particularly troublesome character, owing to the decision  
> to use it for qualified operators back in Haskell 1.3.  It's really  
> too late to change that now, sadly.
>
>> Back to the original argument:
>>
>>  >  Prelude.>>= just doesn't look like an infix operator.
>>
>> I think that
>>
>>   `Prelude.(>>=)`
>>
>> doesn't really look like an infix operator either.
>
> It does begin with a `, just like `Data.List.map`, or `fmap`.  So in  
> that sense it is more like an infix operator than Prelude.>>=.
>
> Anyway, thanks for all the comments in this thread.  I've tried to  
> summarise the pros/cons on
>
> http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
>
> Please let me know if I've missed anything.  The committee will  
> review the arguments when we make final decisions.
>
> I realise this change is not a clear-cut win.  So few things are.   
> It's a question of balancing the advantages against the  
> disadvantages, and reasonable people are very likely to differ.
>
> Cheers,
> 	Simon
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-prime/attachments/20090709/9f16969f/attachment.html