🚀 go-pugleaf

In article <1991May28.141856.26234@maths.nott.ac.uk> anw@maths.nott.ac.uk (Dr A. N. Walker) writes:
>In article <1991May22.185944.10208@netcom.COM> doug@netcom.COM (Doug
>Merritt) writes:
>
>[example of ignorance of both number and type of parameters to a procedure]
>
>>The inner loop of an interpreter: eval(func, parameters).
>
>	But that has [just] two parameters.  If the source is previously
>unscanned, then presumably "func" and "parameters" are of types "string"
>and "array of string" (or perhaps "list of string").  If the source has
>been tokenised, and possibly syntax-checked, etc., then "func" could be,
>for example, "pointer to symbol-table-entry" and "parameters" could be
>"pointer to emulated-stack-frame" or some such.

Nope! I mean the more usual case, where "func" and "parameters" are
completely processed into some internal model, and in the *body* of 'eval'
(as opposed to the *call* of eval()), you have to then call 'func' on
the appropriate parameters.

In the case where 'func' is a builtin function, you need to be able
to call it on an arbitrary number of parameters:
	if (func->addr == sqrt)  (*func->addr)(parameter[0])
	if (func->addr == pow)   (*func->addr)(param[0], param[1])
	if (func->addr == qsort) (*func->addr)(p[0], p[1], p[2], p[3])
	etc
I'm not making this up, this has been an irritation every time I've done
an interpreter (e.g. for lisp or "little languages"). C does not lend
itself to such situations of variable type & number of parameters at all.

>	There are plenty of examples of interpreters and compilers written
>in languages in which the number and type of procedure parameters must be
>statically determinable.

But that's just the point. C is such a language, and it's a real pain.
If you want your interpreter to be able to dynamically generate code,
so that functions defined at runtime can be efficiently called as
if they were hardwired primitives, then it gets even worse. You've got
to explicitly enumerate all possible cases of parameter type and number.
Or build C stack frames on the fly via either external assembler code or
kludgy tricks, all of which are highly nonportable (I've done all these
approaches, and I don't like any of them).

>	This example, "eval (func, params)", differs from the previous
>example, "optimise (func, params)", because "optimise" was intended to
>apply to functions and parameters generated [independently] inside the
>same program, whereas "eval" is intended to apply to functions and
>parameters generated by other programs being inspected by the interpreter.
>Even if "eval" is applied to its own text, it can call on all the other
>facilities of the interpreter, whereas "optimise" has no access to the
>program source.  I hope this distinction is clear!

I hope my explanation of my example makes it clear that there is no
such distinction here. In the Lisp world in particular, there is little
or no distinction between statically defined functions and those defined
at runtime, nor in access to interpreter facilities. (More generally,
in any language in which functions are first class citizens, and even
more especially those in which code generation may be done at runtime.)

Interpreters which operate purely on unscanned strings or even tokenized
sequences are much less common, less powerful, "quick and dirty",
admittedly easier to handle some tricky semantic cases, but also less
interesting for real world applications.
	Doug
-- 
Doug Merritt	doug@netcom.com		apple!netcom!doug