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
Could you explain why you think this proposal would help you avoid lens? If I am not mistaken all of the above code can easily be rewritten in the old syntax without using lens, so you probably have another use case in mind?
Oh that's another big issue, thanks for pointing that out! Accessor functoin collisions was already somewhat solved, but this is a much nicer solution.
That code is copy-pasted by the way, from the proposal.
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."
There's lots of Haskell fanboys (like me ;) who can become a bit annoying, but the people usually recognised as leaders in the community, like Simon Peyton Jones, are all rather sane and pretty pragmatic.
It's a nuanced issue, because Haskell extensively uses the dot (.) infix operator to mean function composition. Currently, the expression `f.g` will attempt to compose the function bound to `f` with the function bound to `g`.
I don't think this is true. The presence of a qualified import of "Data.Set as Set" does not change how the following is parsed.
import Data.Set (fromList)
import qualified Data.Set as Set
data Set a = Set (Set.Set a)
f :: Ord a => [a] -> Set a
f = Set . fromList
g :: Ord a => [a] -> Set a
g = Set .fromList
h :: Ord a => [a] -> Set a
h = Set. fromList
i :: Ord a => [a] -> Set.Set a
i = Set.fromList
In other words, the . is interpreted as a "module dot" if and only if there is no whitespace either preceding or following the dot.
To me it's just, "the dot hugs a field, dot by itself is composition, and module names are capitalized."
While I wouldn't write f. g, if I see it, it's not hugging the field name so it's composition. I don't think I'd have trouble reading it.
But... it will probably trip up newbies and people with odd spacing styles. Hopefully GHC can give a useful error like "In the field selection expression f.g, g is a function defined on XX. Did you mean f . g?"
Whitespace requirement is unfortunate but probably necessary. Changing meaning of . from function composition to anything else will break approximately 100% of existing Haskell libraries.
The breakage problem is interesting. Right now, a.b parses just fine, so existing code will break when this is turned on. And that is an issue as people often turn extensions on per project, but it's also something a code formatter may be able to fix.
(Hopefully britanny will get an update to handle this correctly!)
They could, In Theory, rename the composition operator selectively when this language extension is enabled. That'd mean Prelude has to change what operators it exports depending on what extensions are enabled, which would be horribly magical.
How would this break 100% of existing libraries? Is there a breaking case outside of where an existing composed function and record name are identical? Haskell is a strongly typed language, where that doesn't happen.
Haskell record fields get turned into top-level functions that act as field accessors. That is, if we have a record:
data Student = Student { name :: Text, school :: School }
we end up with two functions 'name' and 'school' in scope that extract the values of their respective fields:
name :: Student -> Text
school :: Student -> School
This means it is common for field names to be composed with functions. I write code like this all the time:
schools = map (schoolId . school) students
This is compounded by the fact that a lot of newtypes use record syntax to define functions in this style that are even named like functions:
newtype Reader r a = Reader { runReader :: r -> a }
Importing runReader from a module, you might not even know that it's implemented as a record field! This is pretty handy since you can change the implementation of runReader from being a record field to a normal function without breaking most of your callers. (In fact, I think this might have happened with runReader being implemented in terms of runReaderT.)
This kind of pattern means that people write lots of code that uses record fields as functions, sometimes without even realizing that they are using a record field!
The practical upshot is that myRecord . someField is used with . as function composition all the time, so any proposal that cares about backwards compatibility can't change the meaning of . in that context.
Rereading now, it seems you're asking how interpreting a . b as record access only if b is a record field in scope would break existing code.
The new record system is implemented on top of a HasField typeclass under the hood. Thanks to the way Haskell's typeclasses work, this means that the instances that define what fields a record has will be in scope when you import the module containing that record—directly or indirectly—even if you don't import the record itself.
This means that even if we do not have a record with a field b in scope, we might still have the instance for some other record in scope—leading to ambiguity in previously unambiguous code. Moreover, even if a . b is unambiguous right now, a record with a field called b might be added somewhere deep in the codebase and cause unexpected ambiguities in the future.
I suppose you could say that a . b is composition whenever a function b is in scope, even if there is also a record with a field called b. That rule would not break existing code, but it also seems inconsistent and confusing—a.b and a . b are sometimes the same and sometimes different, depending entirely on whether b is in scope.
Making the meaning of . purely lexical rather than depending on what's in scope seems a lot more consistent and easier to follow. It's already the case with Haskell anyway, since . can mean function composition or a qualified name depending on the spaces around it. This isn't an ideal situation, but I don't think we can aim for "ideal" in a living language that's 30 years old.
It's ambiguous syntactic sugar, that can only be resolved by applying the semantic type checking pass. That's the kind of sigare that that leads to vexing parses, "causes cancer of the semicolon" as they say.
since basically no other language with dot syntax lets you do myRecord . someField with a space in between, it doesn't seem like something that will actually trip newbies up
i guess i forgot about the newlines case, and just had never seen anyone put spaces in like that without newlines, so figured it didn't exist. strange that it's even allowed.
Numeric literals is a special case (in most languages), since the dot could also be a decimal separator. You have to use space or parentheses to disambiguate.
The lexer could disambiguate but that would require lookahead. I believe Python have a deliberate policy of keeping the parser simple.
But I just noticed C# support this, so it is not the same for all languages. Java doesn't, but then again you cant call methods on numbers in Java anyway.
It's a real lexing ambiguity because '0.' is a valid numeric literal (so '0..toString()' parses ok, somewhat counterintuitively). In principle, yes, you could lex '.' as a separate token even in numeric literals and have the parser figure it all out.
Clearly one character lookahead is not sufficient, because e.g. '0. toString()' (note the space). There's no question that the lexer could in principle disambiguate with unbounded lookahead, but it would be a bit hacky, as you'd effectively be implementing part of the parser in the lexer (by attempting to figure out if if was a method call, which is really the parser's job).
So basically, you could easily write a parser that allowed '0.toString()', but you'd either have to piece numeric literals together in the parser or add nasty hacks to the lexer.
> There's no question that the lexer could in principle disambiguate with unbounded lookahead, but it would be a bit hacky, as you'd effectively be implementing part of the parser in the lexer (by attempting to figure out if if was a method call, which is really the parser's job).
This is actually not hacky. It's just a rule that the "." cannot be followed by [ \t]∗\w, which is a simple negative lookahead assertion. Replace \w with whatever you use at the start of identifiers.
It is extremely common for languages to have corner cases like this in the lexer to make the language more usable. For example, consider the rules in JavaScript or Go concerning where you can put line breaks. Or the rules for JavaScript concerning regular expression literals, which must be disambiguated from division.
> So basically, you could easily write a parser that allowed '0.toString()', but you'd either have to piece numeric literals together in the parser or add nasty hacks to the lexer.
This is factually incorrect. As I explained, you would only need one character of lookahead. There is no need to parse "0. toString()" successfully. If you wanted to parse "0. toString()" correctly, you could use unbounded lookahead, which is fairly simple in practice (speaking as a sometimes parser writer). I don't get why you say it is hacky, this is all just a bunch of regular expression stuff (in the traditional sense of "regular").
>If you wanted to parse "0. toString()" correctly, you could use unbounded lookahead
Right, which is what I said. If you agree that unbounded lookahead is required then we don't really disagree, except on the somewhat subjective question of how 'hacky' that is.
If I understand correctly, you suggest that unbounded lookahead could be avoid by allowing '0.toString()' but not '0. toString()', while still allowing both '(0).toString()' and '(0). toString()' and both 'foo.bar' and 'foo. bar'. That would produce highly counterintuitive results in some instances:
Parsed as one expression:
{}.
foo
Parsed as two statements:
0.
toString()
But again, it is really a subjective judgment. Obviously you could modify Javascript in this way, and on that point there is no disagreement.
For languages with C derived syntax, whitespace around operations are insignificant. "a+b" is the same as "a + b". But by convention, space after dot is very rare.
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?
Yeah, there are still a lot of reasons to use lenses. But to rephrase - i was wondering if lenses and the proposal somehow "interact". Actually, I just found some of what i was after in this comment [1].
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.
That is not an especially big production problem. Of course you don't want it to happen. But it rarely happens. And it happens even less if you use -XStrictData or manually make your record fields strict since that's by far the most common cause: lazy records used as accumulators.
I would say in my 5 years of production Haskell, I've seen that sort of thing deployed in production _maybe_ once, and I've run into it during development once or twice.
One time it was in integration testing, and a simple heap profile made it clear it was in a library dependency. And a quick look at the library source was enough to diagnose it. It was like an hour or two tops from "we have a space leak somewhere" to "here's a PR to a third-party library fixing the leak."
Thanks! Most of my production experience with 'Haskell' was with Standard Chartered's Mu dialect, which is strict anyway.
A bit of a problem when you first start using Haskell seriously is that the IO mechanisms built into the prelude are very slow once you get to even only a few MiB.
That's easily remedied by switching to eg ByteStrings, but it's still a bit annoying that what the language presents as the 'default' is such a toy implementation.
> So maybe it should have been something like "->".
The problem is that "->" has an even more special meaning than "." in Haskell, since "->" separates the arguments of an unnamed function from its definition.
So, for example
addOne = \x -> x + 1
and
addOne x = x + 1
are equivalent.
This means that "->" is about as special as "=". Which leads me to think it would require some very substantial changes to the parser, and perhaps even defeat the purpose of increased readability. For example, how readable is the following?
getY = \x -> x -> y
(which reads as "getY = \x -> x.y" in the current proposal)
I thought conflating the dot with function composition wouldn't be too bad because they're similar in a sense, but then I remembered that the two work in the reverse order in the sense that:
(.a.b.c) . (.d.e.f) = (.d.e.f.a.b.c)
If you use -> both for the member function and for reverse function composition you'd get:
(->a->b->c) -> (->d->e->f) = (->a->b->c->d->e->f)
which is somehow nicer, especially because accessing a member and composing functions become the same thing when you view a value as the unique function sending the initial object to that value.
But unfortunately we've spent centuries composing functions the wrong way round, so now we're forced to deal with the consequences.
You can do left to right function composition with (>>>)
Given functions f, g , h,
h >>> g >>> f is equivalent to f . g . h
Its from Control.Category, so it generalizes to other things, but for functions specifically its left to right composition.
( theres also (<<<), which in this case is identical to (.) )
( Also present in Control.Arrow . Why? I dont know this topic well enough to explain. My understanding is limited to what these operators mean in the specific of functions. Functions(->) are a type as well, so they can be instances of typeclasses. for example
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.
Haskell is full of things (hello, most of Prelude) where the default thing is terrible and the correct thing is in a package (usually a choice between multiple incompatible packages). It makes it extremely uncomfortable to grow from newbie to intermediate.
The cool thing about the `/2` forms of `put_in` and `update_in` is that they are macros they rewrite the ast to return the entire object, and not just the changed value.
To clarify, the thing I want is to make it nice and simple to create a new record with a nested field updated. It's easy to read a.b.c.d, but updating that field painful:
let a = {a with b = { a.b with c = { a.b.c with d = 5 } } } }
which is curried and data-last, so you can keep that setter around for future instances of e. Usually not too bad to translate Ramda into your language of choice, and a valuable exercise. I did it with Python and it helped a TON
The update syntax is actually more of a `.copy` method, than a property update since it returns a new object. It's actually quite nice in that respect since it's easy to update multiple fields:
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.
The old classic languages just create so-called selectors in the global namespace, like defstruct macro does. This is not the best possible solution.
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.
https://github.com/ghc-proposals/ghc-proposals/blob/master/p...