On Sat, Feb 11, 2012 at 5:02 PM, Roman Leshchinskiy
<rl@cse.unsw.edu.au> 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