eo
eo copied to clipboard
Fail to call an array element
This test fails:
[] > x
[y] > add1
y.add 1 > @
(* add1) > arr
(arr.get 0) 33 > @
@dours looks like a bug, thanks for reporting, let me investigate
@dours even this one fails:
[] > applies-a-few-levels
[x] > foo
[y] > @
42 > @
eq. > @
((foo 1) 2)
42
It interprets ((foo 1) 2)
as foo 1 2
. It's probably a bug in EO to XMIR parsing.
@dours this is how we parse (((foo x) y) z) > a
now:
<o base="foo" name="a">
<o base="x" />
<o base="y" />
<o base="z" />
</o>
It seems that we should do this instead, introducing two synthetic attributes a1
and a2
:
<o base="foo" name="a2">
<o base="x" />
</o>
<o base="a2" name="a1">
<o base="y"/>
</o>
<o base="a1" name="a">
<o base="z" />
</o>
@andreoss can you fix this? I think, it's a bug in the parser at the level of ANTLR. Would be great to reproduce it first with PacksTest
. Let's also think carefully about the way we generate the names of these synthetic attributes. Just a1
and a2
is not a good idea. Maybe something like a-θ1
, a-θ2
, etc. To make sure we won't have conflicts too often
@yegor256 Yes, please assign.
@yegor256 These synthetic attributes will be on the same level? How can they have a limited scope?
(((foo x) y) z) > a
Or nested like that?
<o base="a1" name="a">
<o base="z" />
<o base="a2" name="a1">
<o base="y"/>
<o base="foo" name="a2">
<o base="x" />
</o>
</o>
</o>
@andreoss we should get this structrure:
<o base="foo" name="a2">
<o base="x" />
</o>
<o base="a2" name="a1">
<o base="y"/>
</o>
<o base="a1" name="a">
<o base="z" />
</o>
@yegor256 How should this be represented by XeListener
?
((1.bar 2).foo (3.bar 4))
As I understand, it should end up exactly the same as
foo.
bar.
1
2
bar.
3
4
, but the final XML for this relays on wrap-methods
, whereas the code without method
calls requires only plain substitutions as in https://github.com/cqfn/eo/issues/415#issuecomment-1002871532
@andreoss I say "yes" to the first part of your question, but I didn't understand the second part.
@yegor256
To get https://github.com/cqfn/eo/issues/415#issuecomment-1002871532 this structure it's enough to generate aliases inside XeListener
.
But this won't work with ((1.bar 2).foo (3.bar 4))
, because objects will/should be rearranged by wrap-methods
.
Doing aliases after wrap-methods
would be to late, because original expression is lost.
Q: How to generate an alias for (foo x)
and (foo.x 1)
in the same manner?
@andreoss (foo x)
goes to:
<o base="foo">
<o base="x"/>
</o>
while (foo.x 1)
goes to:
<o base=".x">
<o base="foo"/>
<o base="org.eolang.int" data="int">1</o>
</o>
what is the problem?
@andreoss we just need to generate the structure I suggested above, with synthetic attributes. Just suggest a solution :) If you think our current code base has a problem, submit a bug.
@yegor256 Clarified my question a little bit,
@andreoss
(foo x)
goes to:<o base="foo"> <o base="x"/> </o>
This is produced by XeListener
alone,
while
(foo.x 1)
goes to:<o base=".x"> <o base="foo"/> <o base="org.eolang.int" data="int">1</o> </o>
But that requires wrap-method-calls
, the raw output of XeListener
would be
<o base="foo">
<o base=".x">
<o data="int">1</o>
what is the problem?
These two structures are two different to apply the same logic for alliasing to them. May be they should be more similar in some intermediate xml form? I.e
<o base="foo.x"> <!-- alias goes here-->
<o data="int">1</o>
</o>
@andreoss I'm not sure what is "aliasing", but I think what you are suggesting may break a lot of code we already have.
@andreoss in other words, I don't understand what what exactly is the proposal and why do you ask a question here instead of just making a pull request?
@andreoss we try NOT to use GitHub issues as discussion boards. You either suggest a bug and we fix it, or you suggest a fix and we accept it. What is the bug here?
@dours the puzzle #1145 is still not solved.
@dours 3 puzzles #2119, #2120, #2126 are still not solved; solved: #1145, #1167, #2093, #2110, #2122.
@dours 4 puzzles #2119, #2120, #2126, #2175 are still not solved; solved: #1145, #1167, #2093, #2110, #2122.
@dours 3 puzzles #2119, #2120, #2126 are still not solved; solved: #1145, #1167, #2093, #2110, #2122, #2175.
@dours 4 puzzles #2119, #2120, #2126, #2190 are still not solved; solved: #1145, #1167, #2093, #2110, #2122, #2175.
@dours 3 puzzles #2119, #2120, #2126 are still not solved; solved: #1145, #1167, #2093, #2110, #2122, #2175, #2190.
@dours 2 puzzles #2119, #2120 are still not solved; solved: #1145, #1167, #2093, #2110, #2122, #2126, #2175, #2190.