Why no closures?

[Ishpeck]

I'm really quite surprised that this isn't in the FAQ.



Why don't we have closures now?

Code Select Expand

> (define (foo x) (lambda (y) (+ x y)))
(lambda (x) (lambda (y) (+ x y)))
> ((foo 3) 4)

ERR: value expected in function + : x

I can do this in Common Lisp:

Code Select Expand

[16]> (defun foo (x) (lambda (y) (+ x y)))
FOO
[17]> (apply (foo 3) '(5))
8



Was this part of the design philosophy or have we just not done it yet?

[Lutz]

See here:



http://www.newlisp.org/index.cgi?Closures">http://www.newlisp.org/index.cgi?Closures



and here:



http://www.newlisp.org/index.cgi?page=Differences_to_Other_LISPs">http://www.newlisp.org/index.cgi?page=D ... ther_LISPs">http://www.newlisp.org/index.cgi?page=Differences_to_Other_LISPs

[TedWalther]

I'm kind of surprised that example doesn't work.  I know newLISP is dynamically scoped; I assumed that would work even in a dynamically scoped LISP?  Not sure how closures come into it.  Perhaps I better buckle down and read through SICP.

[rickyboy]

No need to go to SICP.  When (foo 3) gets evaluated in newLISP, the value of x is gone from the stack (it gets popped off), and without the environment carried by a closure to remember it, it gets forgotten.  So then the value of (foo 3) (with the lost value of x) gets applied to the argument 4 and the evaluator complains that there is no x.  We might not like this, but it does work as advertized.



For that example to work as the fellow intended, it needs to have the binding of x hang around in an environment (part of the closure) -- if only for a moment.  However, in newLISP, what you want to do is just have any reference to x expanded on the fly.  If this can be done, then in this case, there is no need to have environments hang around.

Code Select Expand

> (define (foo* x) (letex (x x) (lambda (y) (+ x y))))
> ((foo* 3) 4)
7
;; Here's what's really happening with (foo* 3):
> (foo* 3)
(lambda (y) (+ 3 y))
;; Here is what happens with (foo 3):
> (foo 3)
(lambda (y) (+ x y))
;; The following works, because the value of x is still on the stack:
> ((lambda (x) ((lambda (y) (+ x y)) 4)) 3)
7

Of course, closures are neat for other reasons, but in this case, it is no great loss (or any loss), since all you really need to do is just "fill in" the value of x on the fly -- a way for doing that in newLISP is to expand the reference to x in that lambda expression on the fly.



P. S. -- And BTW, having closures will still not make me look sexy in my jeans.  (Little board spam reference there. :)

[TedWalther]

In some sense, a (let ...) block is a closure.  I assumed that (fn ...) acted as a closure in the same way, like a let block.  Thanks for the explanation, ricky.

[Ishpeck]

It's good to see that I'm the one who's the moron.



Thanks for the help, all.

[xytroxon]

Lisp(s) make all mere mortals "morons" at some point...

 

-- xytroxon

[Camryn65]

I am curious of why these wack jobs can not have a decent bone in there body and give us NON'S a sence of closure and at least say our goodbyes in a Mature manor.



I mean What the heck we shared so much together and just to vanish into thin air..Thats just f------g wrong and it en rages me.



What kind of people are they?