Proposal: change to qualified operator syntax
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.
On Tue, Jul 07, 2009 at 05:58:54PM +0200, haskell@henning-thielemann.de 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/
On 07/07/2009 16:58, haskell@henning-thielemann.de 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
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
kahl@cas.mcmaster.ca 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
On 08/07/2009 23:06, kahl@cas.mcmaster.ca 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
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, kahl@cas.mcmaster.ca 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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
On Tue, 7 Jul 2009, haskell@henning-thielemann.de 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.
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
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
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 Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
On 12/07/2009 22:32, haskell@henning-thielemann.de wrote:
On Tue, 7 Jul 2009, haskell@henning-thielemann.de 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
On Mon, 13 Jul 2009, Simon Marlow wrote:
On 12/07/2009 22:32, haskell@henning-thielemann.de 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!
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
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
participants (9)
-
Alexander Dunlap -
Carlton Mills -
Dan Weston -
haskell＠henning-thielemann.de -
John Launchbury -
John Meacham -
kahl＠cas.mcmaster.ca -
Malcolm Wallace -
Simon Marlow