Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!keele!nott-cs!piaggio!anw From: anw@maths.nott.ac.uk (Dr A. N. Walker) Newsgroups: comp.lang.misc Subject: Re: type checking problem Message-ID: <1991May28.141856.26234@maths.nott.ac.uk> Date: 28 May 91 14:18:56 GMT References: <1991May16.182932.26327@kodak.kodak.com> <1991May21.144739.23901@maths.nott.ac.uk> <1991May22.185944.10208@netcom.COM> Reply-To: anw@maths.nott.ac.uk (Dr A. N. Walker) Organization: Maths Dept., Nott'm Univ., UK. Lines: 38 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