Re: defining functions in basin scripts

There have been two kinds of solutions to this that I am familiar with.
One is to have a calculator-like interpreter code that chains together
calls to compiled operations (arithmetic, math functions, etc.) by
placing the intermediate results on an internal result stack. We would
probably want to program the stack and the interpreter to handle any
sort of result that basin could produce, not necessarily just scalars.

One question is whether you want the interpreter to support user-defined
functions defined in terms of the basic operations (or other
user-defined functions), so that one can write more elaborate chains of
operations succinctly, or support reuse of code.

As people get used to the convenience of firing up the interpreter and
defining expressions on the fly, they start writing more extensive code
in the interpreter and then want to make it go fast (i.e. at the speed
that the code would go if it were written directly in C++ and compiled
as a function). Having a translator-to-C++/compile/link in is the
second kind of solution. This has usually been done as an add-on after
the first kind of solution has been implemented. Matlab for example,
has a compile-to-C feature that users seem to like.

I suppose that in this day and age one could also have a just in time
approach where the code compiles as it is used (a potential benefit of
having a system that is not afraid to operate as if there are multiple
threads or processors available). As far as I know this third approach
has not been done yet for math systems.

I think a simple interpreter is the way to go for the time being. We
might eventually have performance evidence that would suggest that
something more elaborate would have a significant payoff.
Received on Fri Aug 19 16:43:06 2005