Quantcast

Proposal: change to qualified operator syntax

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal: change to qualified operator syntax

haskell-3

Adding to an old thread:
   http://www.haskell.org/pipermail/haskell-prime/2008-April/002441.html

I like to note that I'm against this proposal. The example given in
   http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
  namely [Red..] can be easily resolved by adding a space, thus [Red ..]. I
use qualified operators occasionally, since I use NumericPrelude and thus
have to import some things from Prelude in a qualified way. As there will
appear more and more infix operators in libraries along with more name
clashes (e.g. recently discussed List.++ and Monoid.++), qualified
operator names will become not so uncommon. Of course, to keep the spirit
of infix operators, you will better define custom operators locally, but
this is only reasonable if you use an infix operator more than once.
  The current syntax is also in a way consistent, since e.g. (+) coincides
with a two side operator section, which is no longer true with the new
proposal. Also (...) and `...` are dual, which is a nice property.
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: change to qualified operator syntax

John Meacham
On Tue, Jul 07, 2009 at 05:58:54PM +0200, [hidden email] wrote:

>
> Adding to an old thread:
>   http://www.haskell.org/pipermail/haskell-prime/2008-April/002441.html
>
> I like to note that I'm against this proposal. The example given in
>   http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
>  namely [Red..] can be easily resolved by adding a space, thus [Red ..].
> I use qualified operators occasionally, since I use NumericPrelude and
> thus have to import some things from Prelude in a qualified way. As there
> will appear more and more infix operators in libraries along with more
> name clashes (e.g. recently discussed List.++ and Monoid.++), qualified  
> operator names will become not so uncommon. Of course, to keep the spirit
> of infix operators, you will better define custom operators locally, but  
> this is only reasonable if you use an infix operator more than once.
>  The current syntax is also in a way consistent, since e.g. (+) coincides
> with a two side operator section, which is no longer true with the new  
> proposal. Also (...) and `...` are dual, which is a nice property.

Yeah. reading it again, I know this will break my code. I am not sure
whether anyone else does it, but a common idiom for me is

import List as L
import Set as S

if S.isEmpty (x S.\\ y) then y L.\\ x

or somesuch. Are qualified operators really that uncommon? I would think
they would be used fairly often...

        John

--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: change to qualified operator syntax

Simon Marlow-7
In reply to this post by haskell-3
On 07/07/2009 16:58, [hidden email] wrote:

>
> Adding to an old thread:
> http://www.haskell.org/pipermail/haskell-prime/2008-April/002441.html
>
> I like to note that I'm against this proposal. The example given in
> http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
> namely [Red..] can be easily resolved by adding a space, thus [Red ..].
> I use qualified operators occasionally, since I use NumericPrelude and
> thus have to import some things from Prelude in a qualified way. As
> there will appear more and more infix operators in libraries along with
> more name clashes (e.g. recently discussed List.++ and Monoid.++),
> qualified operator names will become not so uncommon. Of course, to keep
> the spirit of infix operators, you will better define custom operators
> locally, but this is only reasonable if you use an infix operator more
> than once.
> The current syntax is also in a way consistent, since e.g. (+) coincides
> with a two side operator section, which is no longer true with the new
> proposal. Also (...) and `...` are dual, which is a nice property.


This proposal cleans up some nastiness in the lexical syntax.  For
example the M.. M... M.... debacle.  How many lexemes in each of those?
in Haskell 98 it's 1, 2, and 3 respectively, whereas with the qualified
operator proposal they are all 2 lexemes.

Yes, you can add spaces to make [Red ..] work.  But why should you have
to, when [1..] works without a space?

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.

Cheers,
        Simon
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: change to qualified operator syntax

Wolfram Kahl
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

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

that with the new proposal, I would have to write

  `Prelude.(>>=)`

which in my opinion only asks for extension of the backquote symtax to
arbitrary epressions, like

  `zipWith (+)`

. 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! ;-)


The QualifiedOperators page also says:

 | You might argue that it is inconsistent to allow `(+)` but not allow
 | (`plus`), but the justification is simply that (..) and `..` are not
 | dual in this design.

I would indeed argue that they should be dual.



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.

If nobody else finds the time to do it,
I'll hack lhs2TeX some day to generate a suscripted presentation,
somewhat like

  |>>=|_{|Prelude|}

from whichever variant will be legal at the time,
and if the choice is among these two variants,
I'd much prefer to type  Prelude.>>=  in my source code.


Wolfram


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: change to qualified operator syntax

Dan Weston
[hidden email] wrote:

> which in my opinion only asks for extension of the backquote symtax to
> arbitrary epressions, like
>
>   `zipWith (+)`
>
> . I frequently run into situations where that would be extremely useful.

What is the fixity and associativity of this infix "operator"? For that
matter, in a let expression

   let (+++++) = (+) in 5 * 2 +++++ 3 - 2

what is the fixity and associativity of (+++++)? Does it inherit these
from (+) by virtue of let? If not, then the obvious local workaround of

   let (>>=) = Prelude.(>>=) in ....  >>=  ...

would not be a drop-in lexical substitution.

> The QualifiedOperators page also says:
>
>  | You might argue that it is inconsistent to allow `(+)` but not allow
>  | (`plus`), but the justification is simply that (..) and `..` are not
>  | dual in this design.
>
> I would indeed argue that they should be dual.

So lexically, given an opening `, is the closing ` the first one
enclosing balanced parentheses?

   2 `(`(`(`(+)`)`)`)` 3 == 5

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

Wouldn't it be much cleaner to outlaw all qualified operators in lieu of
a top-level import:

   import Prelude((>>=) as (>>>=), fst as myFst)

leaving fixity and associativity of operators intact unless overridden:

   import Prelude((+) as (++++))  -- assumes infixl 6 as in Prelude
   infixr 3 ++++                  -- but for this file I will change it

Dan


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: change to qualified operator syntax

Simon Marlow-7
In reply to this post by Wolfram Kahl
On 08/07/2009 23:06, [hidden email] 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
>
>   >  http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
>
> 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 `Data.List.map`, 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

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

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: change to qualified operator syntax

John Launchbury
Simon,

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


John Launchbury   | galois |   (503)626-6616 x104


On Jul 9, 2009, at 4:22 AM, Simon Marlow wrote:

On 08/07/2009 23:06, [hidden email] 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

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

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 `Data.List.map`, 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

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

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


_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: change to qualified operator syntax

haskell-3
In reply to this post by haskell-3

On Tue, 7 Jul 2009, [hidden email] wrote:

> I like to note that I'm against this proposal. The example given in
>  http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
> namely [Red..] can be easily resolved by adding a space, thus [Red ..]. I
> use qualified operators occasionally, since I use NumericPrelude and thus
> have to import some things from Prelude in a qualified way. As there will
> appear more and more infix operators in libraries along with more name
> clashes (e.g. recently discussed List.++ and Monoid.++), qualified operator
> names will become not so uncommon. Of course, to keep the spirit of infix
> operators, you will better define custom operators locally, but this is only
> reasonable if you use an infix operator more than once.
> The current syntax is also in a way consistent, since e.g. (+) coincides
> with a two side operator section, which is no longer true with the new
> proposal.

Should the consistency with operator section also be added as 'cons' to
   http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
  ?

> Also (...) and `...` are dual, which is a nice property.
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Add units - include furlongs/fortnight in addition to SI units

Carlton Mills

  I can't see where this has been proposed, so I will propose it. It is clear that programming languages vars/expressions will be required to carry units in addition to the value. A mission to Mars was botched because of units mismatch that was not caught. The languages F# and Fortress include a way to specify units on a variable and value. The compiler enforces unit conformance.

  I have no idea if automatic conversion is a good idea or not.

  I have no idea what the proper technical term I should have used; thus the use of furlongs in the subject to get attention.

  I don't know if this is difficult or not, but I am reasonable sure that compiler enforced units conformance will be required in government and space agency contracts. (Probably will happen a year after M$ has a good implementation available - this could be a competitive advantage).

-Carlton Mills, Urbana, Illinois


     
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add units - include furlongs/fortnight in addition to SI units

Alexander Dunlap
I think there's a library called "dimensional" or something that does
this sort of thing.

Alex

On Sun, Jul 12, 2009 at 7:44 PM, Carlton Mills<[hidden email]> wrote:

>
>  I can't see where this has been proposed, so I will propose it. It is clear that programming languages vars/expressions will be required to carry units in addition to the value. A mission to Mars was botched because of units mismatch that was not caught. The languages F# and Fortress include a way to specify units on a variable and value. The compiler enforces unit conformance.
>
>  I have no idea if automatic conversion is a good idea or not.
>
>  I have no idea what the proper technical term I should have used; thus the use of furlongs in the subject to get attention.
>
>  I don't know if this is difficult or not, but I am reasonable sure that compiler enforced units conformance will be required in government and space agency contracts. (Probably will happen a year after M$ has a good implementation available - this could be a competitive advantage).
>
> -Carlton Mills, Urbana, Illinois
>
>
>
> _______________________________________________
> Haskell-prime mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: change to qualified operator syntax

Simon Marlow-7
In reply to this post by haskell-3
On 12/07/2009 22:32, [hidden email] wrote:

>
> On Tue, 7 Jul 2009, [hidden email] wrote:
>
>> I like to note that I'm against this proposal. The example given in
>> http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
>> namely [Red..] can be easily resolved by adding a space, thus [Red
>> ..]. I use qualified operators occasionally, since I use
>> NumericPrelude and thus have to import some things from Prelude in a
>> qualified way. As there will appear more and more infix operators in
>> libraries along with more name clashes (e.g. recently discussed
>> List.++ and Monoid.++), qualified operator names will become not so
>> uncommon. Of course, to keep the spirit of infix operators, you will
>> better define custom operators locally, but this is only reasonable if
>> you use an infix operator more than once.
>> The current syntax is also in a way consistent, since e.g. (+)
>> coincides with a two side operator section, which is no longer true
>> with the new proposal.
>
> Should the consistency with operator section also be added as 'cons' to
> http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
> ?

So correct me if I'm wrong; the point you're making is:

              left section  right section   prefix
unqualified  (+ 1)         (1 +)           (+)
Haskell 98   (M.+ 1)       (1 M.+)         (M.+)
proposed     (`M.(+)` 1)   (1 `M.(+)`)     M.(+)
    or(*)     (M.(+) 1)     (flip M.(+) 1)

(*) only if precedence isn't important, e.g. not in cases like (`M.(+)`
x `M.(*)` y).

Cheers,
        Simon
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: change to qualified operator syntax

haskell-3

On Mon, 13 Jul 2009, Simon Marlow wrote:

> On 12/07/2009 22:32, [hidden email] wrote:
>>
>> Should the consistency with operator section also be added as 'cons' to
>> http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators
>> ?
>
> So correct me if I'm wrong; the point you're making is:
>
>             left section  right section   prefix
> unqualified  (+ 1)         (1 +)           (+)
> Haskell 98   (M.+ 1)       (1 M.+)         (M.+)
> proposed     (`M.(+)` 1)   (1 `M.(+)`)     M.(+)
>   or(*)     (M.(+) 1)     (flip M.(+) 1)
>
> (*) only if precedence isn't important, e.g. not in cases like (`M.(+)` x
> `M.(*)` y).


Yes, that's what I meant. Thanks for working it out!
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: change to qualified operator syntax

Malcolm Wallace
>>            left section  right section   prefix
>> unqualified  (+ 1)         (1 +)           (+)
>> Haskell 98   (M.+ 1)       (1 M.+)         (M.+)
>> proposed     (`M.(+)` 1)   (1 `M.(+)`)     M.(+)
>>  or(*)     (M.(+) 1)     (flip M.(+) 1)

The last line is not correct.  (M.(+) 1) captures the first argument  
of the function, not the second like all the other entries in that  
column.  Likewise the flip variant captures the second arg, where all  
the others capture the first.

Regards,
     Malcolm

_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: change to qualified operator syntax

Simon Marlow-7
On 14/07/2009 08:58, Malcolm Wallace wrote:

>>>  left section  right section  prefix
>>> unqualified (+ 1) (1 +) (+)
>>> Haskell 98 (M.+ 1) (1 M.+) (M.+)
>>> proposed (`M.(+)` 1) (1 `M.(+)`) M.(+)
>>> or(*) (M.(+) 1) (flip M.(+) 1)
>
> The last line is not correct. (M.(+) 1) captures the first argument of
> the function, not the second like all the other entries in that column.
> Likewise the flip variant captures the second arg, where all the others
> capture the first.

oops, I got those the wrong way around.  Well spotted.

Fixed on the wiki page:

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

Cheers,
        Simon
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Loading...