Thanks to everyone who replied - the sum of the answers is actually a lot more useful than each one individually, as each one points to a part of the puzzle that Pharo is (for me, at least, after roughly one month of use). Ben Coman <btc@openinworld.com> writes:
This may not be what you are looking for, but maybe help flesh out ideas. Try debugging... OpalCompiler new evaluate: '1 + 2'
An interesting experience indeed! Tim Mackinnon <tim@testit.works> writes:
I was going to chip in that every class inherits what compiler it uses and so you can easily override that to do something special (like wrapping classes).
An interesting feature, though it seems a bit too low-level for my project, and definitely too low-level for my current Pharo competence.
However, is this possibly an area where the meta-links kicks in so you donât have to do this and get a more generic solution? (I havenât played with this, but there are a few threads where people are using it, and itâs progressed quite a lot in Pharo 7).
That sent me off research meta-links: https://pharoweekly.wordpress.com/2018/03/27/understanding-metalinks/ Interesting stuff as well, but the same comment applies: this looks too low-level for what I consider boring code implementing routine techniques. Steffen Märcker via Pharo-users <pharo-users@lists.pharo.org> writes:
Did you already try to measure the impaired overhead of a wrapper solution? It might very well be negligible in an otherwise purely symbolic computation.
I did not look into performance questions at all for now. What scares me most is the overhead in code size, in particular in my test suite.
A hybrid solution might be - instead of wrapping each value - to add a single method to the value classes that wraps a value on the fly if needed, e.g.
Integer>>asExpression ^ExpressionWrapper wrap: self.
That looks like an interesting compromise, and one that I have seen used elsewhere.
Another option might be to build a trait that adds the behavior to the value classes.
A nice suggestion as well - I haven't looked at traits yet in any detail. Serge Stinckwich <serge.stinckwich@gmail.com> writes:
in your case I would write a parser for your specific concrete syntax with PetitParser and then generate an instance of the abstract syntax you have defined.
My first reaction was that this looks like overkill for my problem. But then, considering that I will eventually need a parser anyway, why not start that way and use it in my own test cases? A path worth exploring. Thanks again to everyone - your comments will keep me busy for a while! Konrad.