On Thu, Dec 27, 2018 at 5:43 PM Konrad Hinsen <[email protected]>
wrote:

> Hi everyone,
>
> I am confronted with an implementation choice that I expect to be not so
> rare, and I wonder what "the Pharo way" is for dealing with it. I will
> use a toy example for illustration, my real case is more complex but not
> fundamentally different.
>
> Suppose I want to represent arithmetic expressions that support various
> operations (evaluation, simplification, compilation to whatever
> language, ...). In the textbook discussion, I'd have a class hierarchy
> such as
>
>     Expression (abstract)
>        IntegerExpression
>        VariableNameExpression
>        SumExpression
>        ProductExpression
>        ...
>
> What I really want is not some IntegerExpression, but plain Pharo
> integers, and for variable names I want to use plain Pharo symbols.
>
> From my current understanding of Pharo, my options are
>
>  1. Use wrapper objects for integers and symbols, i.e. have a class
>     IntegerExpression that stores an integer in an instance variable.
>
>  2. Add the methods of my abstract Expression class to all the classes
>     representing integers and symbols.
>
>  3. Implement my own dispatch that does not rely on method lookup.
>
> None of these really looks attractive. 1) adds a lot of overhead, both
> in the code ("IntegerExpression withValue: 5" rather than just "5") and
> at runtime. 3) also adds a lot of overhead because I have to implement
> my own dispatch. 2) would probably be the least effort, but looks like a
> kludge.
>
> For comparison, in the Lisp world (CLOS, Racket, ...) that I know much
> better, I would use generic functions and provide implementations for
> integers and symbols as well as for my own Expression types.
>
> So... how would you approach this problem?
>
>
Hi Konrad,

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.

Regards,
-- 
Serge Stinckwic
h

Int. Research Unit
 on Modelling/Simulation of Complex Systems (UMMISCO)
Sorbonne University
 (SU)
French National Research Institute for Sustainable Development (IRD)
U
niversity of Yaoundé I, Cameroun
"Programs must be written for people to read, and only incidentally for
machines to execute."
https://twitter.com/SergeStinckwich

Reply via email to