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