modules/Compiler: Add AstcodeDecoder

[iglosiggio]

If we want to use the compiler from LMR/Nativization then we need a way to decode our serialized trees into something a bit better.

[melkyades]

hmm, I think there's a small mismatch with this one. The encoder in the compiler generates treecodes (formerly known as astcodes), but the decoder doesn't generate ast nodes back (at least in principle). Instead, it generates SExpression objects, which are ast-like but lower level, thought for execution time where you want to have leaner objects in memory.

I believe a better solution would be to bring the SExpression hierarchy from powerlang/pharo back to a submodule of Compiler, and make the decoder generate SExpressions instead of SParseNode subclasses.

[iglosiggio]

hmm, I think there's a small mismatch with this one. The encoder in the compiler generates treecodes (formerly known as astcodes), but the decoder doesn't generate ast nodes back (at least in principle). Instead, it generates SExpression objects, which are ast-like but lower level, thought for execution time where you want to have leaner objects in memory.

I believe a better solution would be to bring the SExpression hierarchy from powerlang/pharo back to a submodule of Compiler, and make the decoder generate SExpressions instead of SParseNode subclasses.

Agree on that. Using the decoder kinda worked for my usecase on some simple cases (I'm trying to use the SExpressionNativizer) but I now found that there are some differences that require a significant amount of changes.

How should we proceed?

[melkyades]

I believe a better solution would be to bring the SExpression hierarchy from powerlang/pharo back to a submodule of Compiler, and make the decoder generate SExpressions instead of SParseNode subclasses.

How should we proceed?

Well, these changes ought to be discarded in favour of porting the SExpressions code from powerlang. Personally, force pushing on this branch or a new branch would be acceptable solutions