Deep twin in pure Eiffel

[Paolo Redælli]

I've dived in the deep ocean of deep twinning... discovering huge monsters.

As I wrote to Hans some weeks ago, in the beginning of SmallEiffel deep_twin has been implemented in the runtime because the compiler lacked the required object introspection support required to implement deep twinning in pure Eiffel.

I think that the thinner the runtime the better for at least a couple of reasons.

Firstly because the more Eiffel the better... some runtime of course will be always be necessary, but I'd rather hunt bugs in Eiffel than in C. For example deep_twin in the runtime uses static variables and this requires a redesign to achieve thread-safety. I'm sure my threading abilities is too weak to hung bugs across the boundaries of two languages.

Then there's an old dream of mine, i.e. having other backends beside C. Today the world see widespread usage of _javascript_ and WebAssembly, JVM is being used by several languages beside Java like, Scala, Kotlin and so on. There is another reason to thin-out the C runtime: GCC has been offering libgccjit, an API for embedding GCC inside programs (see https://gcc.gnu.org/wiki/JIT and https://gcc.gnu.org/onlinedocs/jit/ ) for a while and we may use it to turn  LibertyEiffel into a "proper" compiler as libgccjut "can also be used for ahead-of-time code generation, for building standalone compilers (so the "jit" part of the name is now something of a misnomer)".

I also shall describe the "monsters" I encountered....

Monsters like making this little change in ANY:

    deep_clone: like Current

        do

            clone(create {HASHED_DICTIONARY[ANY,POINTER])

        end

feature {} -- Deep twin implementation

    clone(already_done: HASHED_DICTIONARY[ANY,POINTER])

    do

        .... something innocent....

        end

an "innocent" change that triggers something into short so that even those addition made "short ANY" explode. I had to kill it after having allocated 4-5Gb of memory.

Then I moved the login into the ad-hoc class DEEP_TWINNER, implemented it in the most "reasonable" way, i.e. using recursion, but recursion coupled with internals triggers an obscure bug in the compiler which does not update the calling stack.

I know that I should have armed myself with the sword of bug solving, but I must confess that I don't know the forest of the compiler enough to dwelve it in a bug hunt.

I'm created a branch in my repository called "deep-twin-in-pure-eiffel". Do you think I can push it in the main repository before I have a viable demo?

Thanks in advance for your time and efforts,

    Paolo