Syntax like Graphics.Collage.defaultLine.color won't compile; you instead have to write .color Graphics.Collage.defaultLine, which is clunky. Since modules are always upper-case and variables are always lower-case (and data constructors don't have fields), I don't think there's any ambiguity. Has this been discussed before?
Weirdly, it has not been brought up! That seems fine to me, just need to slightly modify the parser.
@maxsnew, do you think anything can go wrong if this is allowed?
I don't see how there would be any ambiguity, and it seems like something you would expect to work, so I'd say go for it.
I just encountered this bug in my own work. +1
Gets even hairier when there's more record and less module in the string:
Foo.Bar.a.b ==> (.b Foo.Bar.a)
Foo.a.b.c ==> (.c (.b Foo.a))
I recently ran into this, and I want to note for anyone else who hits this before it is fixed, you can also use an intermediate variable as a workaround. A.b.c becomes d = A.b On another line then d.c Where you wanted A.b.c
Yes, I'd recommend assigning the record to a let-binding, because then accesses relative to that binding Just Work. So instead of:
doSomethingWith SomeModule.someRecord.x.y.z
do:
let
myRecord = SomeModule.someRecord
in
doSomethingWith myRecord.x.y.z
Looks like a fix was provided with #1170, with backing test cases added in #1221. @jdudek mentioned intent to merge #1221 as of 17 Feb 2016, merged master back into the branch to resolve any conflicts, and then progress stalled short of merging into the project.
This issue has come up a couple times in a just a few days in the Elm Slack, so it's an issue that people are brushing up against not irregularly; it'd be great to see this resolved.
Track in #1374
This is fixed by the new parser. Thanks for the report!
Most helpful comment
This is fixed by the new parser. Thanks for the report!