The situation is this: a process, represented as a closure, spawns a
child, another closure. The parent then runs the child, and when the
child finishes it returns to the parent. I am doing this using continuations,
that is, the child is passed the parent closure which it then funcalls
when it has finished. So the parent has to be able to pass itself to the
child.
I can let a closure reference itself in the following way:
(defun make-closure ()
(let (-self-)
(setq -self- #'(lambda ()
<this closure can now reference itself as -self->))))
Does this seem like a particularly bad idea? Is there some important reason
why I would not want to do this? Is there some reason why I wouldn't
want to use SETQ? Can this be done more elegantly? All criticism welcome.
Thanks, Eliot
In article <····@phoenix.Princeton.EDU>, ·····@phoenix (Eliot Handelman)
writes:
>The situation is this: a process, represented as a closure, spawns a
>child, another closure. The parent then runs the child, and when the
>child finishes it returns to the parent. I am doing this using continuations,
>that is, the child is passed the parent closure which it then funcalls
>when it has finished. So the parent has to be able to pass itself to the
>child.
>
>(defun make-closure ()
> (let (-self-)
> (setq -self- #'(lambda ()
> <this closure can now reference itself as -self->))))
>
>Does this seem like a particularly bad idea? Is there some important reason
>why I would not want to do this? Is there some reason why I wouldn't
>want to use SETQ? Can this be done more elegantly? All criticism welcome.
There is no need to use the LET/SETQ combination because the LABELS construct
(CLtL p113) exists exactly for this reason. LABELS allows definition of local
functions that can reference themselves and each other recursively. The above
code can be written as:
(defun make-closure ()
(labels ((-self- () <code that can reference -self-> ))
-self-))
If you really tend towards the boroque you can use "Church's Y operator" which
is defined in Scheme using:
(define (y f)
((lambda (g) (lambda (h) ((f (g g)) h)))
(lambda (g) (lambda (h) ((f (g g)) h)))))
(the CL version would have alot of FUNCALL and #'s thrown in) to make
recursive closures without using "explicit" recursion constructs. Using the
above definition you can make a closure to recursively compute the factorial
function by calling:
(y (lambda (fn)
(lambda (x)
(if (zerop x) 1 (* x (fn (- x 1)))))))
Anyway, LABELS is what you want.
Bruce Krulwich
From: Mark Johnson
Subject: Re: Self-referencing Closures
Date:
Message-ID: <7931@csli.STANFORD.EDU>
Bruce Krulwich is quite correct - the LABELS form is what you need
to make these self-referencing closures. His example contains
a minor bug, however: he forgot to use #' in front of the final -self-
form. The corrected version is:
(defun make-closure ()
(labels ((self ()
(print 'hello)))
#'self))
Too much Scheme! Someone else just sent a message on the net asking
why CommonLisp uses different name spaces for variable and function
definitions. Personally, I think that this is one of the worst
features of CommonLisp. It makes my programs look like fields of #'
symbols and funcalls. It is also one of the hardest things for
students to learn - they get continually confused between the use of
LIST as a function and a variable. (I know it's bad programming
style, but people do do it).
Mark Johnson
From: Jeff Dalton
Subject: Re: namespaces
Date:
Message-ID: <251@skye.ed.ac.uk>
In article <····@csli.STANFORD.EDU> ·······@csli.stanford.edu (Mark
Johnson) writes:
>Too much Scheme! Someone else just sent a message on the net asking
>why CommonLisp uses different name spaces for variable and function
>definitions. Personally, I think that this is one of the worst
>features of CommonLisp. It makes my programs look like fields of #'
>symbols and funcalls. It is also one of the hardest things for
>students to learn - they get continually confused between the use of
>LIST as a function and a variable. (I know it's bad programming
>style, but people do do it).
Return of the Style Wars!
The use of separate name spaces goes back to Lisp 1.5, so it's not
just Common Lisp; most Lisps have been that way. In many ways, Common
Lisp is a traditional Lisp, albeit a big one.
Whether FUNCTION and FUNCALL are good or bad depends, in part, on how
often they're used. If they're relatively rare, they can be useful as
signs that something unusual is happening. For example, FUNCALL
indicates a call to a non-constant function. But if you adopt a more
functional style, so that FUNCTION and FUNCALL are used all over the
place, the resulting clutter may make the code harder to read.
It's not too hard to explain FUNCTION as a syntactic marker, if you
say, as CLtL does, that Lisp programs "are organized as forms and
functions". The Lisp 1.5 syntax went more or less as follows:
<form> ::= ... | (<function> <argument>*) | ...
<argument> ::= <form> | (FUNCTION <function>)
<function> ::= <function name> | <lambda expression>
So FUNCTION is a way to write a function as an argument (or, better,
as a form). FUNCTION used to be more than "just syntax". It was
often sort-of like QUOTE but sometimes an operation that made a
closure, sometimes a marker for the compiler (saying there was
something to be compiled and not just a list there). But it was still
reasonable to think of FUNCTION as syntax.
The issue of name spaces, or multiple meanings for identifiers, is
more difficult. Some people might say it is always wrong to use LIST
as a variable, others might say it's almost never wrong and, indeed,
extremely convenient. Again, this may depend on the sort of code they
write (or want to write). If functional arguments are rare, most
functions are, in effect, constants; and it's not unreasonable to
think, for example, that (COS <form>) should always call the cosine
function.
Indeed, that's more or less what one has to think when writing
a macro. If I write
(defmacro cosine (x) `(cos ,x))
I expect (COSINE x) to return the cosine of x. But I don't really
know that no-one will locally redefine COS. If there is a separate
function namespace, I have to worry about local functions (FLET) only;
but with one name space I have to worry about every variable too. E.g.,
(defun cosine2 (x)
(let ((cos (cosine x))) ;ok
(cosine cos))) ;not ok
In practice, though perhaps not in principle, a single namespace makes
such problems more likely. The macro would work as intended in the
function above if there were a separate function name space.
The example above may not be very convincing by itself, but it should
be clear that such things can happen. And historically that has been
one reason why some people have been reluctant to adopt a single name
space.
---
For an informative discussion of the two namespaces in Common Lisp,
see "Technical Issues of Separation in Function Cells and Value
Cells", by Richard P. Gabriel and Kent M. Pitman, in Lisp and Symbolic
Computation, Volume 1, Number 1, June 1988.
For a discussion of macro problems and how they might be solved, see
"Syntactic Closures", by Alan Bawden, in the Proceedings of the 1988
ACM Conference on Lisp and Functional Programming.
Jeff Dalton, JANET: ········@uk.ac.ed
AI Applications Institute, ARPA: ·················@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
From: Barry Margolin
Subject: Re: Self-referencing Closures
Date:
Message-ID: <37134@think.UUCP>
In article <·····@yale-celray.yale.UUCP> ··············@cs.yale.edu (Bruce Krulwich) writes:
> (defun make-closure ()
> (labels ((-self- () <code that can reference -self-> ))
> -self-))
Actually, the last form should be #'-self-, since LABELS binds the
functional value, not the variable value, of the symbol.
>If you really tend towards the boroque you can use "Church's Y operator" which
>is defined in Scheme using:
You could also simply use LETREC in Scheme. It binds a variable and
arranges for the scope to include the value form.
Barry Margolin
Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
In article <·····@think.UUCP>, ······@think (Barry Margolin) writes:
>Actually, the last form should be #'-self-, since LABELS binds the
>functional value, not the variable value, of the symbol.
>
>>If you really tend towards the boroque you can use "Church's Y operator"
>>which is defined in Scheme using:
>
>You could also simply use LETREC in Scheme. It binds a variable and
>arranges for the scope to include the value form.
Scheme's LETREC is (essentially) the same as CL's LABELS. I was trying to
show something different by discussion the Y operator.
Bruce