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