Bytes of Wisdom - All Comments

re: Seeking Closures

foo — Sat, 06 Sep 2008 08:51:35 GMT

joshua:

EVERY is a function in Common Lisp, see here:

www.lispworks.com/.../f_everyc.htm

You actually don't need the variable to be introduced by LET. Any (lexical) variable will do.

Also:

(let ((a 13) (b 14)) (+ a b))

is conceptually the same as

((lambda (a b) (+ a b)) 13 14)

So you get a closure with:

(defun foo (a) (lambda (b) (+ a b)))

and (foo 13) then is a closure that you can call and will always add 13 to a number: (funcall (foo 13) 22)

Also note that you get a closure from this:

(let ((a 10)) (flet ((add (b) (+ a b))) (function add)))

Any function will do. Local named functions, too.

Above you see that a closure is returned.

You can also pass a closure to another function:

(let ((a 10)) (flet ((add (b) (+ a b))) (mapcar (function add) '(1 2 3 4))))

Above will add 10 to every element of the list and return the result list.

MAPCAR gets passed a closure and calls it with every element of the list as argument.

Sure, go ahead and use the examples...

re: Seeking Closures

Peter — Fri, 05 Sep 2008 18:44:47 GMT

If you're wondering where all the anonymous commenter(s) came from, this article got linked on Reddit: www.reddit.com/.../seeking_closures_so_whats_a_closure_and_why

re: Seeking Closures

jlockwood — Fri, 05 Sep 2008 16:22:39 GMT

@Ramarren

Okay, I see your point. Point taken. :)

@foo

Ah, I see what you are saying...my mistake. Thanks for clearing things up. As you say, "make-comparison" is currently used to create a chunk of code and is not truly a closure.

I've quickly read over your example and found it useful. I'd never seen the "every" function before and couldn't find it in the common lisp command reference that I've been using. I imagine its part of common lisp...ran fine in Allegro CL. With your permission I'd like to update the blog entry to reflect what you've provided.

I appreciate the feedback. I'm but a LISP neophyte, so I'm still figuring a number of things out. I see now that I must always use "let" to bind a variable locally and then I can use it in a closure. I'll have to play with this a bit.

re: Seeking Closures

Jason Meridth — Thu, 04 Sep 2008 19:12:16 GMT

@foo

Why not use your real name here? You have good input. Just curious. Anonymous commenters drive me nuts.

re: Seeking Closures

foo — Thu, 04 Sep 2008 17:49:37 GMT

Here is a version that really uses closures:

lispm.dyndns.org/.../closures-at-work.lisp

You can see that the result of calling (where ...) is a closure - the Lisp systems (LispWorks) also tells us that. There are multiple closures involved. MAKE-COMPARISON-FUNCTION returns a closure. MAKE-COMPARISON-FUNCTIONS returns a list of closures. WHERE also returns a closure.

re: Seeking Closures

Ramarren — Thu, 04 Sep 2008 17:12:27 GMT

Yes, I meant the case. I probably should have said that directly. But really, I wasn't even born in the seventies, so I'm just nitpicking. So, while I'm doing that, Common Lisp is case sensitive, and required to be so by the standard, it is just that it is by default in :upcase mode for compatibility with older LISPs. See: www.lispworks.com/.../23_ab.htm

re: Seeking Closures

jlockwood — Thu, 04 Sep 2008 16:04:33 GMT

@foo

Ah, if that's the case then I misunderstood. I still write it as LISP, even when referencing CL. I didn't even consider case, as the language is not case sensitive (at least with the implementation I'm using). As you stated, everything is evaluated in upcase.

@Ramarren

My apologies if I misunderstood you.

re: Seeking Closures

jlockwood — Thu, 04 Sep 2008 15:59:51 GMT

@Dave

Nice article! I was considering getting into JavaScript, but decided against it because -- although I love JavaScript as a language -- I thought the language syntax might have made things a little confusing. After getting deeper into JavaScript, I began to view functions as class definitions. Closures are central to JavaScript as they are the only means in supporting object-oriented programming in the language.

It's interesting, I think if one views JavaScript through the eyes of a LISPer the language kind of makes more sense. I say this because in LISP the line between code and data is kind of blurred. JavaScript uses the same syntax to define functions as it does data constructs (similar to lisp).

I certainly agree that looking at JavaScript's implementation of closures is quite useful in developing an overall understanding of the concept.

re: Seeking Closures

foo — Thu, 04 Sep 2008 15:52:45 GMT

Joshua: what Ramarren says: Lisp is nowadays called 'Lisp'. In earlier years it was called LISP. Years ago it was all upcase. Even the programs were upcase. Common Lisp has the symbols also internally in upcase format. Nowadays when somebody sees LISP then he thinks of the older Lisp dialects from before the 70s.

re: Seeking Closures

jlockwood — Thu, 04 Sep 2008 15:51:26 GMT

@Justin Paston-Cooper

Come now Justin, you must know that I joke with tounge in cheek! I don't feel that I need to pander to anyone...nor do I try associate with many people for that matter (ask one of my handful of friends...LOL).

In truth, I know of a number of people who are adept at several languages yet still find LISP to be cryptic and even intimidating. I wouldn't doubt that the way some universities present the language contribute to this paradigm.

> I like how you feel the need to pander to the average

> programmer's thoughts of "OH NO ITS NOT A C BASED

> LANGUAGE IT LOOKS DIFFERENT SO IT MUST BE BAD

> AAAAAH"...

The funny things about this is that I've found such attitudes to be more common among some Ruby developers that I've met...they seem to think that there is no other language but theirs. Of course, there is the VB crowd too...

The bottom line is that LISP is not a common language and is often forgotten outside of the university. In spite of this, its influence is becomming increasingly apparent in the mainstream languages that get the most attention. I believe that studying the language will help improve overall programming ability as well as offer clear illustrations of concepts introduced into the languages used daily in the workplace.

If I appeared to pander to one group or another I apologize. I was simply joking about the way LISP is commonly perceived. Its a great language and you don't have to look like the Unibomber to enjoy it!

re: Seeking Closures

foo — Thu, 04 Sep 2008 15:48:33 GMT

Joshua, unfortunately that's not correct. There is no closure.

Look at the source of MAKE-COMPARISON.

It returns a list. The variable LIVING-THING is just a symbol in that list. The macro takes those lists and creates a new list which then gets used as code.

The backquote expression you have there:

`(equal (getf living-thing ,field) ,value)

living-thing is just a symbol in a list. The list is simply like:

(list 'equal (list 'getf 'living-thing field) value)

Evaluate that and you get the result list.

Of course you can't evaluate the result list, because living-thing is nowhere defined. To form a closure you need two things: living-thing needs to be a variable and it needs to reference a definition somewhere. But there is no definition of living-thing around MAKE-COMPARISON.

But yor code later is:

(lambda (lliving-thing) (and (equal (getf living-thing :test) :me)))

Then living-thing is a variable in the lambda-expression. Again no free variable.

You CAN repair your example but then you need to get rid of your macro. Can you imagine how a closure-based version would look like? If not, I'll post a version for you.

Think about it... ;-)

re: Seeking Closures

jlockwood — Thu, 04 Sep 2008 15:13:38 GMT

@Foo

I'm afraid you are incorrect. Perhaps you misread something? The closure is in "make-comparison" and it references the variable (its the parameter) in the lambda expression.

(see the paragraph starting with "The "make-comparison" function works just...")

The article clearly states that "make-comparison" is where the closure is (which is restated in the paragraph describing the marco). One objective of the article is to illustrate that labmda expressions are not closures - which is apparently not understood by same (based on articles that I've read).

The lexical context of the closure is the lambda expression in the macro (which is shown in the example using macroexpand-1). The function "make-comparison" can not be evaluated by itself, since "living-thing" is not a bound variable (hence the closure).

For example:

(eval (make-comparison :test 'me)

would cause the following error:

"attempt to take the value of the unbound variable 'LIVING-THING'."

re: Seeking Closures

jlockwood — Thu, 04 Sep 2008 14:38:52 GMT

@Ramarren

I'm afraid I must repectfully diagree with you, but I do admit that the name came after the language. Here's a little history...to avoid argument I've provided references.

We can use numerous references, but I'll start with wikipedia (1). First off, I agree with the article when it asserts that LISP is actually a family of languages...so Scheme is LISP, just a different dialect. Given that, the term LISP is a symbol referencing all languages in the family allowing us to reference implementations that pre-date the term itself.

The wikipedia article credits John McCarthy as the language designer (in 1958), which I guess is technically true, but it was originally designed strictly as a mathematical notation for describing computer programs (based on lambda calculus). McCarthy first set out to create a programming language for AI (based on list processing) in 1956 (2). The first actual implementation of LISP was written later that year by S. R. Russell (2). Because Russell first implemented LISP on an IBM 704, we now have the obiquitous and funky functions car and cdr (since they were machine instructions native to the platform).

I did find a site that has an image from the LISP 1.5 Programmers Manual which was written by McCarthy et al. in 1962, so it's evident that the language was called LISP much earlier than the 70s (3). McCarthy regarded his new creation as a list processing language from its inception, so I think it's fair to say that the language was indeed LISP as early as 1958.

Thanks for the post and I hope that clears things up a bit.

Cheers!

(1) Lisp (programming language). (2008, September 1). In Wikipedia, The Free Encyclopedia. Retrieved 14:05, September 4, 2008, from en.wikipedia.org/.../index.php(programming_language)&oldid=235653687

(2) McCarthy, John (1996). The implementation of LISP. The History of Lisp. Retrieved 14:08, September 4, 2008, from www-formal.stanford.edu/.../node3.html

(3) McJones Paul, Ed. (2008). History of Lisp. Software Preservation Group. Retrieved 14:10, September 4, 2008,

from www.softwarepreservation.org/.../index.html

re: Seeking Closures

foo — Thu, 04 Sep 2008 14:33:18 GMT

Joshua, but it is clear to you why your Lisp code does not use any closure?

First: an anonymous function is not a closure.

(defun foo () (lambda () 'bar))

Calling foo does not create a closure. A closure is a function that references a variable from the enclosing lexical scope. None of the function you define does that.

Second: the closure is a function and its bindings:

See this:

(defun make-counter (start increment) (lambda () (let ((value start)) (incf start increment) value)))

MAKE-COUNTER returns a closure, since the LAMBDA expression references START and INCREMENT, which are defined outside the lambda expression. The closure then is the anonymous function plus the bindings for START and INCREMENT.

If you look at your code, none of the functions references variables that are introduced by its lexical surroundings.

You simply don't explain anything about closures here.

re: Seeking Closures

David Alpert — Thu, 04 Sep 2008 14:13:18 GMT

Another interesting discussion of closures is taking place in the JavaScript space (e.g. blog.morrisjohns.com/javascript_closures_for_dummies).

If not identical to the way closures operate or are implemented in modern LISP, Java, or .NET, then at least JavaScript closures might be another way into the concept.