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
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Locked
