Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!mcsun!ukc!warwick!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: <1991May29.153720.15287@maths.nott.ac.uk>
Date: 29 May 91 15:37:20 GMT
Article-I.D.: maths.1991May29.153720.15287
References: <1991May21.144739.23901@maths.nott.ac.uk> <1991May22.185944.10208@netcom.COM> <1991May28.141856.26234@maths.nott.ac.uk> <1991May28.191001.12219@netcom.COM>
Reply-To: anw@maths.nott.ac.uk (Dr A. N. Walker)
Organization: Maths Dept., Nott'm Univ., UK.
Lines: 54

In article <1991May28.191001.12219@netcom.COM> doug@netcom.COM (Doug
Merritt) writes:

>Nope! I mean the more usual case,

	[as opposed to "unscanned" or "tokenised" -- ANW]

>				   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.

	But then there are two cases:

  a) "func" is user-provided.  The parameters are "arbitrary", but the
     whole mechanism is under the interpreter's control.

  b) "func" is built-in.  The parameters are dictated by the requirements
     of the host libraries.  Somewhere there will be some indication of
     what parameters are required [checked either during processing or by
     "eval", according to taste], and we get something like your code
     [deleted].  Slightly messy, agreed, but not disastrous, and really
     the opposite of the case in question -- so far from the parameters
     being unknown, they are only too well known.  Given something like a
     "lint" library, you could construct the switch body and the relevant
     part of the symbol table automatically, in case the list of built-ins
     is changing.

>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.

	This is right at the compiled end of the spectrum between
text-based interpreters, through tokenisers and threaded code, towards
full-blown compilers.  It's not surprising that you have to write
code comparable in complexity [and non-portability] with a full
compiler in order to interface your interpreter with compiled code.

	Note that in (Classic) C, the number and type of function
parameters *is* unspecified, and it doesn't seem to have bought you
anything ("printf" and friends always excepted).  In other words,
I'm happy to sympathise with your problems, and agree that C doesn't
provide all the answers in a convenient way;  but this doesn't have
much to do with allowing arbitrary parameters.

>Interpreters which operate purely on unscanned strings or even tokenized
>sequences are much less common,

	"Hush, hush, whisper who dares,
	    Before BASIC catches you, all unawares." [:-)]

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