Complicated translation result

[deemp]

Hi! I tried to translate the following snippet:

def myC():
    class c:
        value = 11
        def getValue(self): return self.value
    class d(c): pass
    o = d()
    return o.getValue() == 11

Expected something similar to this, but got

memory > xd
memory > xc
[] > sample
  [args...] > unsupported
  [args...] > xunsupported
  memory > bogusForceDataize
  memory > xbogusForceDataize
  memory > xhack
  seq > @
    xhack.write
      []
        memory > xmyC
        seq > @
          xmyC.write
            []
              memory > xgetValue
              memory > xvalue
              memory > xo
              seq > @
                seq
                  (((unsupported)) 0)
                    seq
                      xvalue.write 11
                      xgetValue.write
                        [xself]
                          seq > @
                            (((unsupported)) (((xself).xvalue)))
                  (((unsupported)) ((xc)))
                  xo.write (((xd)) 0)
                  (((unsupported)) ((((((xo).xgetValue)) 0).eq 11)))

[dours]

@br4ch1st0chr0n3 Hello. Thank you for describing your expectations. What steps do you follow to generate EO? You should have recieved this output (it is even more complicated than what you got above): simplest-derived-class.txt

The following text applies to the output that you should have actually received as mentioned above.

TLDR: My generator must be able to support different general python features, which do not happen in this particular example. I try to explain them below. I could elaborate more on the explanation. Please tell me, which of the generalizations hurt you most, so that I reflected on how to simplify them.

Some explanations:

1. value is mutable, so we cannot generate 11 > value, we must generate cage > value and then assign 11 to value somewhere else during dataization. "Somewhere else" is called initFields in my code. It is called before calling a constructor
2. getValue is also mutable! One can define a function getValue and then assign an integer to getValue. This is allowed in python, so getValue must also be a cage, which stores an object with the function. Currently it is implemented with an anonymous object with a single field called apply. More fields should be added later because each function in python has fields (!), for example, the __class__ field
3. python has return. This means that I must support quitting a function at any place inside the function's code. This is implemented with the help of the goto object in EO, which has a kind of "calling convention". So, each function, including getValue must be wrapped in an object to be called with the goto
4. in addition to return, python has exceptions and break/continue. They are supported through the same mechanism as the return, which forces me to analyze each returned value to check if it is actually a returned value or an exception or a break/return. This part is described here Memo: implementation of break and exceptions in python with goto in EO objectionary/eo#618 . This is why getValue() is called like

tmp.write (goto ((((e2)).apply ((lhs0))).@))
(tmp.xclass.xid.neq (return.xclass.xid)).if (stackUp.forward tmp) 0

5. A class in python acts like a function. Basically, calling a class is like calling a constructor, which returns an object. A function is called with the help of goto, so a class is also called the same way: (goto ((((xd)).apply).@)) creates an object of the class d.
6. EO has lazy evaluation by default, python is eager by default and the evaluation order is documented, so I have to force it. I do this by splitting each expression in parts, generating them in the right order, forcing them in that order by dataizing their .< field
7. EO has a strange pecularity, which is documented here Recursive update exception: assignment to a cage with lazy right hand side is a problem! objectionary/eo#462, it must be workaround as described here Recursive update exception: assignment to a cage with lazy right hand side is a problem! objectionary/eo#462, that is, by creating a lot of explicit "copies" to avoid possible cycles. Maybe, I can simplify this part.

[deemp]

Hi! Thank you for your comprehensive feedback. We need some time to discuss it with the odin team.

Regarding the output, I got it by following the instructions from README. However, it refers to an old version of the transpiler. Please, update the link (also suggested here).