Re: Proposal: require spaces around the dot operator
On 02/11/2012 09:21 PM, Roman Leshchinskiy wrote:
On 12/02/2012, at 02:04, Greg Weber wrote:
I am sorry that I made the huge mistake in referencing future possible
proposals. If this proposal passes, that has no bearing on whether the
other proposals would pass, it just makes them possible.
Please help me fix my error by stopping all discussions of future
proposals and focusing solely on the one at hand.
But if we don't consider those future proposals, then what is the justification
for this one? It does break existing code so there must be some fairly
compelling arguments for it. I don't think it can be considered in isolation.
Does it help your concern about breaking existing code to make sure this
proposal has a LANGUAGE flag? ("-XDotSpaces" or such)
(I'm guessing that helps somewhat but not very satisfactorily; the more
default and standard it becomes, the more often it tends to break code
anyway.)
-Isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
This proposal stands on its own * the dot operator is inconsistent with Module function selection. * we are allowed the option of expanding the usage of the dot without spaces if this proposal goes forward. The point is that we will decide whether or not to expand the usage of the dot in the *future*. We could decide on a completely different usage than record field selection. If this proposal is not compelling enough on its own we should merge it with other proposals and discuss them together as a single new concrete proposal. Let me know if that doesn't make sense. I am unfamiliar with the process for this mail-list and obviously led things in the wrong direction. On Sat, Feb 11, 2012 at 6:21 PM, Roman Leshchinskiy wrote: > On 12/02/2012, at 02:04, Greg Weber wrote: > >> I am sorry that I made the huge mistake in referencing future possible >> proposals. If this proposal passes, that has no bearing on whether the >> other proposals would pass, it just makes them possible. >> >> Please help me fix my error by stopping all discussions of future >> proposals and focusing solely on the one at hand. > > But if we don't consider those future proposals, then what is the > justification for this one? It does break existing code so there must be some > fairly compelling arguments for it. I don't think it can be considered in > isolation. > > Roman > > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
On 12/02/2012, at 02:04, Greg Weber wrote: > I am sorry that I made the huge mistake in referencing future possible > proposals. If this proposal passes, that has no bearing on whether the > other proposals would pass, it just makes them possible. > > Please help me fix my error by stopping all discussions of future > proposals and focusing solely on the one at hand. But if we don't consider those future proposals, then what is the justification for this one? It does break existing code so there must be some fairly compelling arguments for it. I don't think it can be considered in isolation. Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
I am sorry that I made the huge mistake in referencing future possible proposals. If this proposal passes, that has no bearing on whether the other proposals would pass, it just makes them possible. Please help me fix my error by stopping all discussions of future proposals and focusing solely on the one at hand. Thank you! Greg Weber On Sat, Feb 11, 2012 at 5:39 PM, Roman Leshchinskiy wrote: > On 12/02/2012, at 01:29, Nate Soares wrote: > >> If -> was introduced for accessing fields, we'd have to discuss whether it >> should have spaces around it. I'd lean towards requiring that it have no >> spaces when used for field access, for symmetry with "." when used for >> module access. > > I'm not spaces matter in this case, -> is a reserved token so we would just > have expressions of the form expr -> field with no special lexical rules. > BTW, if -> doesn't work for some reason then there is also => which AFAIK > isn't used in expressions at all currently. > > Roman > > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
On 12/02/2012, at 01:29, Nate Soares wrote: > If -> was introduced for accessing fields, we'd have to discuss whether it > should have spaces around it. I'd lean towards requiring that it have no > spaces when used for field access, for symmetry with "." when used for module > access. I'm not spaces matter in this case, -> is a reserved token so we would just have expressions of the form expr -> field with no special lexical rules. BTW, if -> doesn't work for some reason then there is also => which AFAIK isn't used in expressions at all currently. Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
I'm very +1 on using -> for field access, I think it's a nice compromise. I doubt there are ambiguities considering that arrow do-notation ( http://www.haskell.org/ghc/docs/7.2.2/html/users_guide/arrow-notation.html) managed to use "->" without trouble. One possible concern is stomping on the feet of arrow do-notation, but I'm not sure we care about ghc language extensions. If -> was introduced for accessing fields, we'd have to discuss whether it should have spaces around it. I'd lean towards requiring that it have no spaces when used for field access, for symmetry with "." when used for module access. Yes, this would add *another* operator that is different when there are no spaces around it, but I think that it's a better approach than breaking a ton of existing haskell code. On Sat, Feb 11, 2012 at 5:02 PM, Roman Leshchinskiy wrote: > On 10/02/2012, at 02:41, Greg Weber wrote: > > > There are 2 compelling reasons I know of to prefer dot for record access > > 1) follows an almost universal convention in modern programming languages > > 2) is consistent with using the dot to select functions from module > name-spaces > > I don't understand what you mean by "consistent" in 2). The TDNR proposal > quite explicitly says that X.f and (X).f mean very different things. This > isn't consistent, IMO, it's actually exactly the same inconsistency we have > now. > > > We can have a lot of fun bike-shedding about what operator we would > > prefer were these constraints not present. Personally I wouldn't care. > > However, I find either one of these 2 points reason enough to use the > > dot for record field access, and even without a better record system > > the second point is reason enough to not use dot for function > > composition. > > > > It is somewhat convenient to argue that it is too much work and > > discussion for something one is discussing against. The only point > > that should matter is how existing Haskell code is effected. > > Huge amounts of existing Haskell code are broken by this. To me, that > should override all other considerations. If Haskell is to be seen as a > real-world programming language, then breaking code in this way simply > shouldn't be acceptable. > > I also don't really understand why it makes sense to take clear, concise > and well-established syntax away from a very frequently used language > feature and use it for (at least in my experience) a less widely used > language feature without an equally clear and concise alternative for the > former. Isn't the net effect less readable code? > > As an aside, could -> be used for field access? I don't think it > introduces any ambiguities (although it's late and I'm probably mistaken) > and there are well-known precedents in other programming languages. > > Roman > > > > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
On 10/02/2012, at 02:41, Greg Weber wrote: > There are 2 compelling reasons I know of to prefer dot for record access > 1) follows an almost universal convention in modern programming languages > 2) is consistent with using the dot to select functions from module > name-spaces I don't understand what you mean by "consistent" in 2). The TDNR proposal quite explicitly says that X.f and (X).f mean very different things. This isn't consistent, IMO, it's actually exactly the same inconsistency we have now. > We can have a lot of fun bike-shedding about what operator we would > prefer were these constraints not present. Personally I wouldn't care. > However, I find either one of these 2 points reason enough to use the > dot for record field access, and even without a better record system > the second point is reason enough to not use dot for function > composition. > > It is somewhat convenient to argue that it is too much work and > discussion for something one is discussing against. The only point > that should matter is how existing Haskell code is effected. Huge amounts of existing Haskell code are broken by this. To me, that should override all other considerations. If Haskell is to be seen as a real-world programming language, then breaking code in this way simply shouldn't be acceptable. I also don't really understand why it makes sense to take clear, concise and well-established syntax away from a very frequently used language feature and use it for (at least in my experience) a less widely used language feature without an equally clear and concise alternative for the former. Isn't the net effect less readable code? As an aside, could -> be used for field access? I don't think it introduces any ambiguities (although it's late and I'm probably mistaken) and there are well-known precedents in other programming languages. Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
On Sat, Feb 11, 2012 at 4:07 PM, Doug McIlroy wrote: > For example, this code fragment to define addition on lists > is instantly intelligible. > > instance Num a => Num [a] where > (f:fs) + (g:gs) = f+g : fs+gs > > But the formula becomes merely an obscure procession of symbols when > rewritten with the operators set off by spaces: > > ( fs : gs ) + ( g : gs ) = f + g : fs + gs I wouldn't require them inside parentheses, but that's a very good point: the list constructor in patterns is an example of an operator where basically no one ever uses spaces. > > And it becomes too long and too subtly modulated to take in at > a glance if more spacing is added to emphasize precedence: > > ( f : fs ) + ( g : gs ) = f + g : fs + gs I would rather write (f + g) : (fs + gs), but point taken. In any case, while I would in theory support spaces around all operators, modulo counterexamples such as those presented above, I'm not proposing it and I don't think anyone is, so it's probably best to stick to discussing spaces around (.) (which I also support). Apologies for taking the discussion off topic. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
> +1 to the idea of requiring spaces around all operators. > It's just good style > Cutting things close syntactically just because you can is perhaps > not the best of ideas Haskell is mathematical both in substance and style. I would not lightly prohibit the use of spacing conventions that have proved over centuries to aid in understanding syntactic strucure. For example, this code fragment to define addition on lists is instantly intelligible. instance Num a => Num [a] where (f:fs) + (g:gs) = f+g : fs+gs But the formula becomes merely an obscure procession of symbols when rewritten with the operators set off by spaces: ( fs : gs ) + ( g : gs ) = f + g : fs + gs And it becomes too long and too subtly modulated to take in at a glance if more spacing is added to emphasize precedence: ( f : fs ) + ( g : gs ) = f + g : fs + gs Doug McIlroy ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
