Proposal: change to qualified operator syntax

Isaac Dupree isaacdupree at charter.net
Fri Jul 11 17:04:43 EDT 2008


Simon Marlow wrote:
> Dan Weston wrote:
>> Would it not be cleaner just to disallow infix notation of qualified 
>> operators altogether? It is clear enough to use "import qualified" or 
>> let or where clauses containing prefix notation to identify a 
>> qualified operator with an unqualified one:
>>
>> UGLY:
>>
>> m `Prelude.(>>=)` a
>>   `Prelude.(>>=)` b
>>   `Prelude.(>>=)` c
>>
>>
>> CLEAR:
>>
>> m >>= a >>= b >>= c
>>   where (>>=) = Prelude.(>>=)
>>
>> [Personally, I prefer where to let for such purely syntactic details].
> 
> I did consider doing that, and it is certainly an option.  The reasons I 
> chose to allow the infix forms are:
> 
>  - if you add an import and introduce a name clash, then you want
>    to resolve clashes by just modifying the names, not by
>    refactoring code.  The trick from your example above works,
>    but it requires that all instances of (>>=) are
>    in scope qualified, otherwise you get a shadowing warning.
> 
>  - it's cheap in terms of grammar and implementation.

Also, I just had a dream about this last night... The other advantage is 
that `Prelude.(>>=)` has the same infix precedence as the imported 
operator (right?), whereas if you want the same for your local synonym 
then you'll have to explicitly give the synonym an appropriate e.g. 
infixl 1 >>= in the where statement.

Fortunately I like the proposal, (1) Have any implementations 
implemented it yet?

(2) as for (`p`), (`Prelude.(>>=)`) not being allowed (even though `` 
sections are, and parenthesized ops-names like (+) are) : I think we can 
make this less of an issue by giving a decent error message for it 
rather than "parse error on input `)'" (e.g. "`(`...`)' isn't allowed 
because it's equivalent to `...'")

Do (1) or (2) have/need GHC trac tickets now?

-Isaac


More information about the Haskell-prime mailing list