From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!deine.net!hamster.europeonline.net!newsfeed.europeonline.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader3.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: about functions that return functions. References: Mail-Copies-To: never From: Erik Naggum Message-ID: <3225030587448391@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 64 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Mar 2002 17:49:36 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader3.kpnqwest.net 1016041776 193.71.199.50 (Wed, 13 Mar 2002 18:49:36 MET) NNTP-Posting-Date: Wed, 13 Mar 2002 18:49:36 MET Xref: archiver1.google.com comp.lang.lisp:28773 * Jordan Katz | Everyone who responded seems to think I'm thinking in Scheme, and, as far | as I can tell it seems to be rooted in what I wrote above, but I don't | see why. You have asked a very typical Scheme question, and people are somewhat sensitive to this sort of question because Scheme victims keep asking it over and over. It seems that this one-namespace thing acts like a virus that takes over the host system to produce more of its own kind. The problem is one of faulty reasoning and muddy thinking, and this is also typical of Scheme victims. | CMUCL groks ((lambda (x) (+ x 1)) 1) for me just like a Scheme would, it | doesn't only accept (funcall (lambda (x) (+ x 1)) 1). Is that a liberty | taken by CMUCL authors to make it more friendly for Schemers, or is that | in accordance with CL specs? This has already been asnwered with a reference to the Hyperspec. Please pay attention, or you just annoy people. Perhaps you did not understand the answer you got. Let ma assume you did not, and try a different angle: (foo ...) calls the function named foo. ((lambda ..) ...) calls the "anonymous" function that _is_ (lambda ...). Kent calls the function itself its name, but I find that confusing -- your name is _not_ your identity, it is a label on your identity. An anonymous function has its own identity as a function, but no name. Specifically, it _is_ a function. Now, you can call the function directly, or you can call it by its name, which the compiler will resolve for you to either be the lexically defined functionn or the globally defined function that is the value of the symbol with the name you gave. The first position in a form either _is_ a function or _names_ a function. (In addition to all the other types of operators, of course.) Now, how is this different from Scheme and from your faulty reasoning? Suppose you think that (lambda ...) _evaluates_ to a function when it is in the first position of a form. This is clearly not how Common Lisp does it, because it expressly does _not_ evaluate the first position, but it _is_ how Scheme does things. If you did not pay much attention to the differences in evaluation rules between Scheme and Common Lisp -- and it seems you have not really studied the evaluation rules of either language just sort of adopted them by osmosis (example) -- you would perhaps think that the operator is somehow evaluated in a different way in Common Lisp. But Common Lisp does expressly _not_ evaluate the operator. The operator either is a function or names a function. So if you place something there that would need to be _evaluated_ to produce a function, it is just not how Common Lisp does things. In summary, ((lambda ...) ...) works because it _is_ a function, not because it _evaluates_ to a function. In (funcall (lambda ...) ...), (lambda ...) evaluates to a function, and the _function_ funcall is called with a regular evaluated value. I quote from the standard and its entry on funcall: The difference between funcall and an ordinary function call is that in the former case the function is obtained by ordinary evaluation of a form, and in the latter case it is obtained by the special interpretation of the function position that normally occurs. Note the special interpretation. /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.