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 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. On Thu, Feb 9, 2012 at 8:27 PM, Daniel Peebles wrote:

I'm very happy to see all the work you're putting into the record discussion, but I'm struggling to see why people are fighting so hard to get the dot character in particular for field access. It seems like a huge amount of work and discussion for a tiny bit of syntactic convenience that we've only come to expect because of exposure to other very different languages.

Is there some fundamental reason we couldn't settle for something like # (a valid operator, but we've already shown we're willing to throw that away in the MagicHash extension) or @ (only allowed in patterns for now)? Or we could even keep (#) as a valid operator and just have it mean category/lens composition.

Thanks, Dan

On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber wrote:

...

Similar to proposal #20, which wants to remove it, but immediately less drastic, even though the long-term goal is the same. This helps clear the way for the usage of the unspaced dot as a record field selector as shown in proposal #129.

After this proposal shows clear signs of moving forward I will add a proposal to support a unicode dot for function composition. After that we can all have a lively discussion about how to fully replace the ascii dot with an ascii alternative such as <~ or <<< After that we can make the dot operator illegal by default.

This has already been discussed as part of a records solution on the ghc-users mail list and documented here: http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

-1. I agree with John. There is no point in fiddling with the dots, until we have real experience with a new records proposal (which can be implemented entirely without using dot, at least initially). Regards, Malcolm On 10 Feb 2012, at 03:14, John Meacham wrote:

I mean, it is not worth worrying about the syntax until the extension has been implemented, used, and proven useful to begin with. Monads were in use well before the 'do' notation. Shaking out what the base primitives that make up a monad took a while to figure out.

Even discussing syntax feels a little like a garage band discussing what the lighting of their stage show will look like before they learned to play their instruments.

If we can implement it and test it without breaking existing code, why wouldn't we? It would mean more people can experiment with the feature because they wouldn't have to modify existing code much. So we will have more feedback and experience with how it interacts with other aspects of the language.

John

On Thu, Feb 9, 2012 at 6:41 PM, 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

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.

On Thu, Feb 9, 2012 at 8:27 PM, Daniel Peebles wrote:

...

I'm very happy to see all the work you're putting into the record discussion, but I'm struggling to see why people are fighting so hard to get the dot character in particular for field access. It seems like a huge amount of work and discussion for a tiny bit of syntactic convenience that we've only come to expect because of exposure to other very different languages.

Is there some fundamental reason we couldn't settle for something like # (a valid operator, but we've already shown we're willing to throw that away in the MagicHash extension) or @ (only allowed in patterns for now)? Or we could even keep (#) as a valid operator and just have it mean category/lens composition.

Thanks, Dan

On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber wrote:

...

Similar to proposal #20, which wants to remove it, but immediately less drastic, even though the long-term goal is the same. This helps clear the way for the usage of the unspaced dot as a record field selector as shown in proposal #129.

After this proposal shows clear signs of moving forward I will add a proposal to support a unicode dot for function composition. After that we can all have a lively discussion about how to fully replace the ascii dot with an ascii alternative such as <~ or <<< After that we can make the dot operator illegal by default.

This has already been discussed as part of a records solution on the ghc-users mail list and documented here: http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator

_______________________________________________ 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

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

+1 to the idea of requiring spaces around all operators. It's just good style -1 to using dot for record fields, however. That's too likely to confuse someone, especially if we end up having something like lenses baked into the language. (Please, please...) On Feb 10, 2012 7:19 PM, "Brandon Allbery" wrote:

On Fri, Feb 10, 2012 at 04:37, Malcolm Wallace wrote:

...

I agree with John. There is no point in fiddling with the dots, until we have real experience with a new records proposal (which can be implemented entirely without using dot, at least initially).

I would claim this should have been done back when hierarchical modules were added.

More generally, it seems to me the Haskell spec has a number of places where potentially colliding syntactic elements are expected to be disambiguated by the compiler, with effects ranging from restricting future syntactic modifications (such as with the present arguments over (.)) to the now-removed impossible brace insertion semantics of Haskell98. Cutting things close syntactically just because you can is perhaps not the best of ideas; in this case, we'd be adding spaces both syntactically and metaphorically (in terms of "expansion space" in the spec), which I suspect is a good idea in general.

(To provide an example not related to the records discussion, every so often the question comes up of providing proper support for character sets which don't have an upper/lowercase distinction, where currently you can't declare types --- or, less often noted, use module names from those csets. Fixing this is likely to complicate parsing periods even more than record.field syntax would.)

-- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

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

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

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

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

On Sun, Feb 12, 2012 at 3:51 PM, Ben Millwood wrote:

On Sun, Feb 12, 2012 at 2:42 AM, Isaac Dupree wrote:

...

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

Anything is allowed to happen if you have a LANGUAGE flag, but we're discussing what ought to be standardised.

I think "existing code breaks" is not a great argument since we can just compile it with Haskell98 (or 2010) switches, although updating code is going to be a nuisance.

[...]

On reflection I take this back, it would be a real nuisance to have to do this. The rest of what I said stands independently of that, of course. -1 to spaces around dot. I could be persuaded regarding spaces around all operators: a quick survey of code I write suggests minimal changes would be necessary. What about the comma, though? Spaces around that would be pretty unnatural; it's already not /quite/ a real operator, but I think that's a shame, and maybe it ought to be. So I'm not voting on that proposal yet, although my instinct is I don't like it.

On 02/10/2012 06:09 AM, Gábor Lehel wrote:

On Fri, Feb 10, 2012 at 4:42 AM, Isaac Dupree wrote:

...

I support requiring spaces around the dot operator, *even if* we don't ever end up using it for anything else.

+1.

I would support requiring spaces around _all_ operators. I can't immediately think of any operator where it would be detrimental, at least, albeit my memory is not the greatest.

FWIW, it's pretty common to sometimes omit spaces around arithmetic operators +, -, *. This was common enough to derail the idea to make negative integer literals be lexed ( "-", no space, numeric literal ). So you'd have to fight that battle. I think spaces around all operators sounds nice in a new language; I'm not sure about Haskell. -Isaac

On 12 February 2012 18:00, Evan Laforge wrote:

On Thu, Feb 9, 2012 at 6:11 PM, Greg Weber wrote:

...

Similar to proposal #20, which wants to remove it, but immediately less drastic, even though the long-term goal is the same. This helps clear the way for the usage of the unspaced dot as a record field selector as shown in proposal #129.

I'm hoping the eventual resolution for the whole record thing doesn't involve dots, rather, that it does but is using them for composition. So I don't want to support something that will break hundreds of lines of code (I often use dot without spaces) for the sake of maybe supporting something I think there are better solutions to in the first place!

What's more, if records use dot as composition then not only do we not need to worry about breaking tons of code and what meaning to give to (.f) and (f.) sections, but I'll use even more space-less dots, to compose together record labels :)

I agree with this. In reading over this discussion, I have often wondered how people seem to have forgotten that *to Haskell programmers* the dot means composition. We shouldn't worry so much about how Java programmers read Haskell code, because obviously, syntax is not the biggest hurdle to their understanding it anyway. We should be concerned with how the people who are using Haskell every day read the dot. Sure, dot is also in the syntax for module selection, but at least for my part I find even that much painful. I specifically go out of my way to avoid using module qualifiers whenever possible because it looks like composition and makes expressions hard to read. I will append abbreviations of the module name to identifiers if I think that they will conflict with other exports in the same project. I would avoid using records because of it, and where I couldn't do so, I would end up writing wrapper functions around field selections just to avoid using dots for something other than composition. That would be sad, I think. Almost any other string of symbol characters would be less painful. Composition is by a good margin my most used infix operator, and should be pretty common, I think, in any functional programmer's code. Not only that, but dot is a *good* notation for it. It's visually quiet, and it's easy to type on every keyboard/terminal combination in existence. By comparison, record selection is a far less important operation and can be given a less pretty name. Personally, just using a prefix (named) function to select a field seems completely adequate to me, but we could invent some other string of symbols for people who want to write it infix. Or, just an idea, recordValue{fieldName} could translate into whatever function is used to select the field, mimicking construction syntax. - Cale