Shoham%YALE@sri-unix.UUCP (11/01/83)
From: Yoav Shoham <Shoham@YALE>
Richard issued a "a reply to his critics", and I was surprised to
find myself listed among them. It is exactly because I prefer
"pure" code that I asked for a "pure" implementation of generated
lists, or lazy lists as he refers to them. His comments were
instructive, if a little pointed. To be more specific, let me
review some of them briefly:
1. "[copying] could be implemented very easily in C or MACRO-10"
- good, but in the meanwhile...
2. "It is not at all difficult to implement [copying] in Prolog
using "var" and "univ" " - right, and that's the pure solution
I alluded to originally. However, that solution (at least the
one I've managed to come up with) is very expensive, and about
90% of the time is spent on tearing structures apart and creating
new ones.
3. The assert and retract of the copying should not be seperated -
absolutely right. (The reason they ARE in my code is because
this code originated in a different task involving the
implementation of data-dependency in Prolog. There the copy is
tampered with in the intermediate code, and thus the seperation).
Again, Richard's remark is correct, and I've added the "copy"
predicate to my utility library.
4. The implentation of glists should make them look like ordinary
Prolog objects - that's exactly what my implementation does
(see next/2). next/1 is only optional if the list is to be
global, as one would want it to be in a data-dependency network.
If you don't like it, ignore it. In fact, Richard's implentation
does not pass enough of the structure around - see next and final
remark.
5. Richard's nice implementation - raises a few questions. First,
I don't know how apply/2 is defined; presumably it employs a
copying mechanism similar to mine (the "copy" predicate?). Is that
really the case? If so, it is a larger source of impurity than
the two mentioned by Richard. If "apply" doesn't import
additional impurity, I'm interested to see its definition.
Second, in the membership test Richard only passes around the
last element generated, so he couldn't create the list "all prime
numbers". (This deficiency is really easy to correct). Richard
also restricts Step to be fixed, so his implentation of the list
[1,2,4,7,11,...] will presumably be awkward. Finally, Richard's
use of the first argument as both input and output via the
unbound variable is more elegant than my straightforward solution.