Fail to call an array element

[dours]

This test fails:

[] > x
  [y] > add1
    y.add 1 > @
  (* add1) > arr
  (arr.get 0) 33 > @

[yegor256]

@dours looks like a bug, thanks for reporting, let me investigate

[yegor256]

@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.

[yegor256]

@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>

[yegor256]

@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

[andreoss]

@yegor256 Yes, please assign.

[andreoss]

@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>

[yegor256]

@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>

[andreoss]

@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

[yegor256]

@andreoss I say "yes" to the first part of your question, but I didn't understand the second part.

[andreoss]

@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?

[yegor256]

@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?

[yegor256]

@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.

[andreoss]

@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>

[yegor256]

@andreoss I'm not sure what is "aliasing", but I think what you are suggesting may break a lot of code we already have.

[yegor256]

@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?

[yegor256]

@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?

[0pdd]

@dours the puzzle #1145 is still not solved.

[0pdd]

@dours the puzzle #1167 is still not solved; solved: #1145.

[0pdd]

@dours the puzzle #2093 is still not solved; solved: #1145, #1167.

[0pdd]

@dours the puzzle #2110 is still not solved; solved: #1145, #1167, #2093.

[0pdd]

@dours 2 puzzles #2119, #2120 are still not solved; solved: #1145, #1167, #2093, #2110.

[0pdd]

@dours 3 puzzles #2119, #2120, #2122 are still not solved; solved: #1145, #1167, #2093, #2110.

[0pdd]

@dours 3 puzzles #2119, #2120, #2126 are still not solved; solved: #1145, #1167, #2093, #2110, #2122.

[0pdd]

@dours 4 puzzles #2119, #2120, #2126, #2175 are still not solved; solved: #1145, #1167, #2093, #2110, #2122.

[0pdd]

@dours 3 puzzles #2119, #2120, #2126 are still not solved; solved: #1145, #1167, #2093, #2110, #2122, #2175.

[0pdd]

@dours 4 puzzles #2119, #2120, #2126, #2190 are still not solved; solved: #1145, #1167, #2093, #2110, #2122, #2175.

[0pdd]

@dours 3 puzzles #2119, #2120, #2126 are still not solved; solved: #1145, #1167, #2093, #2110, #2122, #2175, #2190.

[0pdd]

@dours 2 puzzles #2119, #2120 are still not solved; solved: #1145, #1167, #2093, #2110, #2122, #2126, #2175, #2190.

[0pdd]

@dours 3 puzzles #2119, #2216, #2217 are still not solved; solved: #1145, #1167, #2093, #2110, #2120, #2122, #2126, #2175, #2190.

[0pdd]

@dours 2 puzzles #2119, #2216 are still not solved; solved: #1145, #1167, #2093, #2110, #2120, #2122, #2126, #2175, #2190, #2217.