🚀 go-pugleaf

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.  [A symbol-table-entry
will naturally be of a fixed type, known to the interpreter, even though
it may well include a description of dynamic types constructed on the fly
by the program being interpreted.]

	There are many other possibilities, but I cannot see any reason
why "eval" has to be ignorant of how it is to be called [even if the
language being interpreted is inherently extensible, or the interpreter
can itself be interpreted].

	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.

	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!

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk