Closed kustosz closed 5 years ago
Description This is a complex issue. The real solution should be implemented in passes, probably in desugaring, as this situation is very similar to wildcard handling.
The old approach
The old parser translates a .foo.bar
to application between Var "a"
and AccSection ["foo", "bar"]
, a core constructor of form AccSection { path :: Vec16 Name }
. The constructor is deprecated, as it supports only named sections and discards information about code spans. We want to support code like foo (. bar 1 . baz)
, so we cannot assume the sections are always names. Moreover, we should not have a special construction in AST if we can express exactly the same information using existing constructions.
The current results
The result we get right now are 100% correct. The code a .foo.bar
generates the following AST:
App
(Var "a")
(InfixApp
(SectionRight (Operator ".") (Var "foo"))
(Operator ".")
(Var "bar")) :|
[]
The AST is correct and until we think about dots like about a very special syntax, not just regular operators, this is the expected output.
Possible solutions
We've got 3 solutions available here:
We could consider dot to be a very special syntax, not a regular operator anymore and such cases would generate a new type of core, like AccSection { path :: LinksTo Terms }
. IMO this is wrong because of few reasons:
As this AST structure is completely correct, it should be handled in passes (probably in the desugaring pass). The answer if we should go this way depends on how hard would it be to implement. Other than possible high time requirements (to be confirmed) it does not has any disadvantages.
Making hack to current parser implementation. After parsing we can traverse the whole AST searching for this AST structure pattern and translate it to the old, obsolete approach. It would require approx 1 day to be implemented (either mine or @mikusp as he already knows the code of AST -> IR translator), but it's also ugly as hell as it requires manual code spans merging and it's a very short term solution. I'm afraid we don't have the choice here and we need to implement it this way.
Works ok ;)
Please ensure that you are running the latest version of Luna before reporting the bug! It may have been fixed since.
General Summary
In the 1.5 version of Luna (new parser) expressions like
.foo.bar
do not work properly, rendering most of my projects unusable. Expressions like[1,2,3].each .succ.pred
parse to something like[1,2,3].each (.succ).pred
, which results in type errors. This is a new behavior since 1.4 where things worked properly.Steps to Reproduce
Use an expression like
[1,2,3].each .succ.pred
. Results in type error about not being able to call a method on a function. Pretty printer shows it as[1,2,3].each (.succ . pred)
, instead of[1,2,3].each .succ.pred
how it used to be in 1.4.Expected Result
Same behavior as 1.4
Actual Result
Broken semantics
Luna Version
1.5