--- Begin Message ---
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 <b...@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.stinckw...@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.
--- End Message ---
