For those that want to see what it actually looks like:<p><a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0282-record-dot-syntax.rst#examples" rel="nofollow">https://github.com/ghc-proposals/ghc-proposals/blob/master/p...</a><p><pre><code> data Grade = A | B | C | D | E | F
data Quarter = Fall | Winter | Spring
data Status = Passed | Failed | Incomplete | Withdrawn
data Taken =
Taken { year :: Int
, term :: Quarter
}
data Class =
Class { hours :: Int
, units :: Int
, grade :: Grade
, result :: Status
, taken :: Taken
}
getResult :: Class -> Status
getResult c = c.result -- get
setResult :: Class -> Status -> Class
setResult c r = c{result = r} -- update
setYearTaken :: Class -> Int -> Class
setYearTaken c y = c{taken.year = y} -- nested update
getResults :: [Class] -> [Status]
getResults = map (.result) -- selector
getTerms :: [Class] -> [Quarter]
getTerms = map (.taken.term) -- nested selector</code></pre>
Simon Peyton Jones: "One possible reaction to a diversity of opinion is to do nothing and wait for clarity to emerge. That is often the right choice, but not (I believe strongly) in this case. We have waited a long time already -- I have been engaged in debate about this topic for over two decades -- and I think it's time to decide something."
Possibly recommend changing link to the proposal itself[1]?<p>Both pages link to each other, but the discussion is unlikely to be of very much note unless one has already read the proposal being discussed.<p>1. <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0282-record-dot-syntax.rst" rel="nofollow">https://github.com/ghc-proposals/ghc-proposals/blob/master/p...</a>
Nothing is better than seeing the broken pieces of the foundation fixed in Haskell.<p>Records were my number one gripe in the language that otherwise does so many advanced things so uniquely well.
It looks sane and solidly specified. I never trusted DisambiguateRecordFields, so I'll finally ditch a lot of ugly prefixes I stuck in there.<p>The whitespace requirements, though, are going to lead to some confusing error messages for newbies who want to type myRecord . someField
Does the proposal have any effect on lens usage?<p>EDIT: I mean, lenses and RecordDotSyntax both provide a way to access nested fields in records, so the new syntax would take away some of the reasons to use lenses. But are there any other relations among the two, or do lenses and RecordDotSyntax just provide two different solutions to the same problem?
Wow this is great! Fixing Haskell's arcane record system would be a huge step towards more mainstream adoption. It was certainly my largest pain point with the language over years of use in production.
Imho this looks good. It will save on key strokes and maybe bring more readability. I always liked "." or "->" syntax in different languages.<p>My only worry is . being function composition operator so it might not be crazy amazing for readability only you get<p>a . b . c . d.e<p>So maybe it should have been something like "->".
PureScript, which borrows heavily from Haskell's syntax (you could say it is Haskell for JavaScript but with strict evaluation) already had something like this for syntax for accessing records (JS objects). It wisely didn't also use the dot for function composition however. I hope it will be the norm to use some alias other than (.) for function composition when this extension is used.
The syntax to update records doesn't seem particularly nice:<p><pre><code> e{lbl = val}
</code></pre>
Though this has been a part of haskell for a while it seems:<p>> Note: e{lbl = val} is the syntax of a standard H98 record update<p>FSharp, OCaml and Elm have not got great solution here either:<p><pre><code> { e with lbl = value } // ocaml/fsharp
{ e | lbl = value }
</code></pre>
Do any functional languages have anything as nice as:<p><pre><code> e.lbl = value</code></pre>
As record slot's value retrieval (I love old lisp terminology) could be viewed as a pure function (given the record as a parameter) it is reasonable to think of .slot as a function.<p>The old classic languages just create so-called selectors in the global namespace, like defstruct macro does. This is not the best possible solution.<p>However, the . is used for function composition, so the better alternative could be the -> syntax, reflecting that in Haskell everything is a pointer.
What's sad is that only reason this situation is so controversial is because all of programming language design is constrained by the 19th Century typewriter keyboard.