Steve Knight writes:
>[5] I don't like keyword parameters/optional parameter etc and dislike
>paying a cost for a feature I don't use
This is perhaps from his point of view of a user of Poplog Common Lisp, who
does have to pay somewhat more for this feature than his Lucid-using sisters
and brothers. Some of the cost could be eliminated by better optimisation.
However I think there is a real need for variadic functions (as they are known
in POP-11). They "happened" originally in POP-1 for much the same reason that
they happened later in Forth and PostScript, namely as a consequence of the
target machine being a stack machine. However they were preserved in POP-2
(somewhat to Rod Burstall's disquiet I believe, since he had to write the
spec. for how they were supposed to work) because it seemed desirable to be
able to write functions which returned the closure of a variadic function.
Arrays - which are mutable functions in POP-11 - are an example. The function
newarray was conceived as returning a closure of an access function which
would be variadic, with the number of arguments determined at the call time of
newarray. E.g.
newarray([1 10 1 10], nonop +)
returns an array initialised to the addition function. Memoisation is another
related example, and one that is, I believe under-exploited. Recently I tried
memoising the tak benchmark in POP-11, and was able to beat C by a handsome
margin (6 times faster I recall). Thus there is a real theoretical reason
for having variadicity, and it is not just a convenience.
He also writes:
> It's interesting to relate the discussion of call/cc to the experience of
> using "processes" in Poplog. (The "process" facilities in Poplog are a dual
> of the Scheme call/cc facilities in that each can be used to (fairly)
> directly implement the other.) Since the two facilities are very closely
> related -- I used Poplog "processes" to implement call/cc in my
> Scheme compiler -- the comparison is useful.
(a) Is this Scheme compiler locked up in the proprietorial coils of HP, or
might some of us load it into our Poplogs?
(b) Nevertheless, I do not believe that the Poplog process mechanism is
efficient enough to use for continuation-intensive applications like Prolog.
It certainly was noticably expensive in the back-tracking experiments we
did with POP-2 in the early '70's.
Poplog Prolog does not in fact use the process mechanism, and is not
competitive in raw Prolog-power with the "pure" Prologs like Quintus -
tho' the co-presence of languages like Common Lisp and POP-11 make it
possible to provide superior performance with a mixed language
implementation of many applications (and more conveniently than
the main-line Prolog approach of using C). I have speculated about
whether "lightweight" Procedure Activation Records could be supported in
Poplog, just for the support of Scheme and Prolog, but no definitive answer
has emerged.
Robin Popplestone.