Proposal: change to qualified operator syntax

[Simon Marlow-7]

Folks,

Please comment on the following proposed change to qualified operator
syntax:

   http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators

Cheers,
        Simon

_______________________________________________
Haskell-prime mailing list
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime

[Dan Weston]

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].

Dan

Simon Marlow wrote:

> Folks,
>
> Please comment on the following proposed change to qualified operator
> syntax:
>
>   http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
>
> Cheers,
>     Simon
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime@...
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
>

_______________________________________________
Haskell-prime mailing list
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime

[Sittampalam, Ganesh]

> Please comment on the following proposed change to qualified operator
> syntax:

>
http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators

I like this change. It'll break a bit of my code, but I think it's worth
it. The point of having infix operators is to write natural looking
code,
and qualifying them completely negates that benefit IMO.

Ganesh

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================

_______________________________________________
Haskell-prime mailing list
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime

[Simon Marlow-7]

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.

Cheers,
        Simon

> Dan
>
> Simon Marlow wrote:
>> Folks,
>>
>> Please comment on the following proposed change to qualified operator
>> syntax:
>>
>>   http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
>>
>> Cheers,
>>     Simon
>>
>> _______________________________________________
>> Haskell-prime mailing list
>> Haskell-prime@...
>> http://www.haskell.org/mailman/listinfo/haskell-prime
>>
>>
>

_______________________________________________
Haskell-prime mailing list
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime

[Isaac Dupree]

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
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime