Proposal: change to qualified operator syntax

John Launchbury john at
Thu Jul 9 14:06:33 EDT 2009


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 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 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
>>  >
>> 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 ``, 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
> 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

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Haskell-prime mailing list