Proposal: require spaces around the dot operator

[Nate Soares]

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 <rl at 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
>
>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20120211/43141787/attachment.htm>