Re: seeking embeddable statement compiler code

Silvius Rus <rus@tamu.edu> wrote in message news:01-11-126...
> Bruce Varley wrote:
>
> > The expression needs to be able to contain 4 variable elements whose
> > values can be adjusted on consecutive calculations. Typically, it
> > would be something like:
> >
> > a * ( b + cos(2.5 - c) * sqrt(d))
> >
> > Typically, one function would read the input string and generate the
> > codified version. A second function would insert the values for the 4
> > variables then evaluate the expression.
>
> If you are looking for papers on this issue I would suggest trying
> "Partial Evaluation" as a keyword.
>
> There are many known solutions to this problem, and the ones I know
> fall somewhere between the following extremes.
>
> At one end, you could write an interpreter for the expression
> language. The code would be pretty slow as every evaluation would be
> based on a traversal of the graph that represents your expression.
> This traversal cannot be optimized very well by compilers as the
> expressions are only available at run-time. You would probably have to
> write a couple hundreds lines of C++ code to implement it.


Why not translate his expression to Polish notation using top-down
recursive descent, and write or find an interpreter that evaluates the
expression using a LIFO stack? I see no need to traverse a graph.


Even though his example expression uses math functions, in the
interpreter, he can call the math functions.


Depending on what you (correctly) call his cost model, it may make
sense to save ASCII polish expressions to avoid the compilation, but
not the interpretation, penalty. That is save the example he gave as


        a b 2.5 c - cos + d sqrt *


One detail would be lexical analysis.


He could use lexx and yacc. It sounds like they are available on his
platform.
> At the other end, you could write the expression into a file as text,
> wrap a function stub around it and run a compiler on it. The
> resulting code would be as fast as it gets. There is a big price to
> pay though as you would have to run the compiler, load the resulting
> code and link to it, everything at run-time. This approach is easier
> to implement (in terms of lines of code), if your operating system
> offers dynamic library primitives such as "dlopen" and "dlsym".


If the original poster is developing shrinkwrap code, this can create
horrendous licensing problems.
[RPN is certainly a little faster to interpret than a parse tree. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.