#'(lambda ... (lambda
Luke Crook
(setf (symbol-function 'double) #'(lambda (x) (* x 2)))
is the same as:
(setf (symbol-function 'double) (lambda (x) (* x 2)))
Why doesn't the setf in the latter return an error when it tries to evaluate
the lambda expression ? Is the #' implied ?
If that is the case, then why is:
(eq #'double (first (list #'double)))
not equivalent to:
(eq double (first (list double)))
-Luke
Rahul Jain
> I was wondering why this:
>
> (setf (symbol-function 'double) #'(lambda (x) (* x 2)))
>
> is the same as:
>
> (setf (symbol-function 'double) (lambda (x) (* x 2)))
#'(lambda ...) is a read-macro abbreviation for
(function (lambda ...))
(lambda ...) is specified as a macro that expands to
(function (lambda ...))
So they are simply synonyms. Choosing one over the other is purely
stylistic (now that SERIES understands normal LAMBDA forms properly :).
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain
> If that is the case, then why is:
>
> (eq #'double (first (list #'double)))
>
> not equivalent to:
>
> (eq double (first (list double)))
Oops, sorry, forgot to respond to this half of the question.
The "#'double" and "double" in your code are both in value positions.
The plain double looks up the variable binding of the symbol 'double
in the current scope.
The #'double expands to (function double), which looks up the function
binding of the symbol 'double in the current scope.
Gabe Garza
> I was wondering why this:
>
> (setf (symbol-function 'double) #'(lambda (x) (* x 2)))
>
> is the same as:
>
> (setf (symbol-function 'double) (lambda (x) (* x 2)))
Because LAMBDA is a macro which expands (lambda (x) (* x 2)) into a
form equivalent to #'(lambda (x) (* x 2)) after the latter has been
read.
They're actually both notations for (function (lambda (x) (* x 2))).
#' is a reader macro which causes the form after it to be expanded
into (function THE-FORM) during the call to read. For example "#'X"
is read as "(FUNCTION X)"; "#'(LAMBDA (x) (+ x 2))" is read as
"(FUNCTION (LAMBDA (X) (+ X 2)))".
LAMBDA is a regular macro: "(lambda (x) (+ x 2))" is read as
"(lambda (x) (+ x 2))", which is macroexpanded into
"(function (lambda (x) (+ x 2)))".
Gabe Garza
Luke J Crook
"Rahul Jain" <rj...@sid-1129.sid.rice.edu> wrote in message
news:87vgasv...@photino.sid.rice.edu...
Luke J Crook
still confuses me..
(defun our-remove-if (fn lst)
(if (null lst)
nil
(if (funcall fn (first lst))
(our-remove-if fn (rest lst))
(cons (first lst) (our-remove-if fn (rest lst))))))
Here, (funcall fn ()) is called without a #' before the fn.
However in the following situation
(setf (symbol-function 'double) #'(lambda (x) (* x 2)))
(funcall double 100) ... fails..
(funcall #'double 100) ... works..
[You can probably tell that I'm busy working my way through "On Lisp", by
Paul Graham.]
Could you please explain why, when a function is passed as functional
argument, the #' is dropped?
-Luke
"Gabe Garza" <g_g...@ix.netcom.com> wrote in message
news:d6x0tm...@kynopolis.org...
Kent M Pitman
> Thank you for the reply. With that in mind, the following different example
> still confuses me..
>
> (defun our-remove-if (fn lst)
> (if (null lst)
> nil
> (if (funcall fn (first lst))
> (our-remove-if fn (rest lst))
> (cons (first lst) (our-remove-if fn (rest lst))))))
>
> Here, (funcall fn ()) is called without a #' before the fn.
>
> However in the following situation
>
> (setf (symbol-function 'double) #'(lambda (x) (* x 2)))
>
> (funcall double 100) ... fails..
>
> (funcall #'double 100) ... works..
>
> [You can probably tell that I'm busy working my way through "On Lisp", by
> Paul Graham.]
>
> Could you please explain why, when a function is passed as functional
> argument, the #' is dropped?
It isn't. It was never there.
The issue isn't the type of the object passed, the issue is the namespace.
Bindings in DEFUN and LAMBDA are in the 'variable' namespace. Variables
are named by saying their name. FN and LST in
(DEFUN WHATEVER (FN LST) ...)
are variable bindings. To access them, you just say FN or LST. These might
contain any kind of object, though presumably by your choice of name you
intend the first to be a function and the second to be a list.
There is also a 'function' namespace which is specifically reserved for
functions. That doesn't mean you can't hold functions in the variable
namespace, but you can't put numbers or hash tables in the function namespace.
The function namespace is a set of names that are accessed when you put the
name in the operator position of a form. e.g., (car x) gets CAR from the
function namespace, not the variable namespace.
If you did
(defun strange (list)
(list list list list))
(strange 3) => (3 3 3)
________________ These names are resolved in the variable namespace.
vvvv vvvv vvvv
In (list list list list)
^^^^
This names is resolved in the function namespace
The FUNCTION special operator allows you to grab something form the function
namespace and put it in the variable namespace. If you want to make a list
of the list function, you can do
(strange #'list) => (#<Function LIST> #<Function LIST> #<Function LIST>)
or you can do
(list #'list #'list #'list)
One important reason for doing this is so you don't have to pick stupid
names list LST for your variables. Binding a variable name LIST will not
keep the list function from being available in the body of your definition.
For example,
(defun string-lengths (list)
(mapcar #'(lambda (string) (list string (length string)))
list))
(string-lengths '("alpha" "beta"))
=> (("alpha" 5) ("beta" 4))
This is because in this:
(defun string-lengths (list)
(mapcar #'(lambda (string)
(list ; <-- This is a function reference, undisturbed
; by your having bound LIST above
string
(length string)))
list)) ;<-- This is a variable ref to the function argument.
Rahul Jain
> Could you please explain why, when a function is passed as functional
> argument, the #' is dropped?
The functional argument is passed to the function and bound to the
_variable_ value of some identifier. Therefore, you don't want the
function binding of that identifier; rather, you want the (normal)
value of it.
Martin Thornquist
> [You can probably tell that I'm busy working my way through "On Lisp", by
> Paul Graham.]
I wonder, is this your first Lisp book? As you seem to struggle with
such basic, yet possibly strange to non-Lispers, concepts as symbols,
maybe you'd be better off with reading a more introductory book first,
e.g. Graham's ANSI Common Lisp (or at least parts of such a book). On
Lisp is not quite an introductory book, but rather a fine continuation
of e.g. ANSI Common Lisp.
Martin
--
"An ideal world is left as an exercise to the reader."
-Paul Graham, On Lisp
Erik Naggum
| I was wondering why this:
|
| (setf (symbol-function 'double) #'(lambda (x) (* x 2)))
|
| is the same as:
|
| (setf (symbol-function 'double) (lambda (x) (* x 2)))
They are not the same. They have the same effect. Lots of things have
the same effect. Just because two things have the same effect, does not
mean you can use the difference as basis for any inference about other
things that are similarly different without understanding the cause.
Quite elementary logic, this. If you do not command a reasonable level
of reasoning, you will go wrong in so many wasteful ways that you should
go back to study reasoning and logic, and not attempt to stumble along
with random guesswork and clueless trial and error.
| Why doesn't the setf in the latter return an error when it tries to
| evaluate the lambda expression?
Look it up in your favorite Common Lisp reference. Things like this are
very well explained in every serious introduction to Common Lisp, and
then you have the specification.
But how did you manage to write this code in the first place? It is so
odd to mess with the symbol-function slot of a symbol without knowing
what #' means or how the macro lambda works.
///
--
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.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
Luke J Crook
news:xunelhg...@brodir.ifi.uio.no...
> [ Luke J Crook ]
>
> > [You can probably tell that I'm busy working my way through "On Lisp",
by
> > Paul Graham.]
>
> I wonder, is this your first Lisp book?
First book, yes. However I have been working a few other of resources on the
net, http://psg.com/~dlamkins/sl/contents.html being one example. I
downloaded On Lisp as it was available online.
> As you seem to struggle with
> such basic, yet possibly strange to non-Lispers, concepts as symbols,
Lisp is quite different to anything I have learnt. And pretty much
everything about Lisp is strange to non-Lispers.
I think if programming languages were to be compared to preparing a meal,
then Lisp would be the old Italian chef who makes his pasta from scratch.
Other languages seem more like the student who throws a TV dinner into the
microwave. The chef might be slower but his guests will have a lot less
indigestion after the fact.
> On
> Lisp is not quite an introductory book, but rather a fine continuation
> of e.g. ANSI Common Lisp.
Thanks for the pointer. I will definitely make that my next purchase.
-Luke
Thomas F. Burdick
> I think if programming languages were to be compared to preparing a meal,
> then Lisp would be the old Italian chef who makes his pasta from scratch.
> Other languages seem more like the student who throws a TV dinner into the
> microwave. The chef might be slower but his guests will have a lot less
> indigestion after the fact.
Actually, Lisp tends to be very fast to use, once you get the hang of
it. Even if I'm not planning on writing something in CL, I've been
known to play around with an initial prototype in CL because it's so
fast to put together. Then I have more chance to play with ideas. To
continue the cooking metaphor, I'd say Lisp is more like a balloon
whisk -- it might appear more difficult to use for someone used to an
electric gizmo, but it will beat those egg whites up faster and
higher, once you learn to use it right.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Rahul Jain
> I think if programming languages were to be compared to preparing a meal,
> then Lisp would be the old Italian chef who makes his pasta from scratch.
Except that that chef would have automated the act of making the pasta
from scratch using robots who do it just right. :)
Luke J Crook
"Thomas F. Burdick" <t...@famine.OCF.Berkeley.EDU> wrote in message
news:xcvzo02...@famine.OCF.Berkeley.EDU...
> "Luke J Crook" <lcr...@socal.rr.com> writes:
>
> Actually, Lisp tends to be very fast to use, once you get the hang of
> it. Even if I'm not planning on writing something in CL, I've been
> known to play around with an initial prototype in CL because it's so
> fast to put together. Then I have more chance to play with ideas. To
> continue the cooking metaphor, I'd say Lisp is more like a balloon
> whisk -- it might appear more difficult to use for someone used to an
> electric gizmo, but it will beat those egg whites up faster and
> higher, once you learn to use it right.
And yet strangely wives still demand a $250 Kitchen Aid. :)
-Luke
Luke J Crook
> "Luke J Crook" <lcr...@socal.rr.com> writes:
>
> > Could you please explain why, when a function is passed as functional
> > argument, the #' is dropped?
>
> The functional argument is passed to the function and bound to the
> _variable_ value of some identifier. Therefore, you don't want the
> function binding of that identifier; rather, you want the (normal)
> value of it.
This took several minutes to sink in but I understand now, thanks. Please
see my reply to Kent Pitman for my rambling thought process.
-Luke
Luke J Crook
"Kent M Pitman" <pit...@world.std.com> wrote in message
news:sfwlmbo...@shell01.TheWorld.com...
> "Luke J Crook" <lcr...@socal.rr.com> writes:
>
> > Could you please explain why, when a function is passed as functional
> > argument, the #' is dropped?
>
> It isn't. It was never there.
I should probably have made my question clearer. I was confused as to the
mechanism that allowed the defun macro to distinguish between a symbol with
a value attribute and a symbol with a function attribute. At first I thought
that defun might be doing something like (fboundp ...) on each variable and
acting accordingly, i.e. bind (symbol-function 'func1) to fn and bind
(symbol-function 'var1) to lst.
After reading through your post, and the previous post by Rahul Jain I went
back and did some more "stumble along with random guesswork and clueless
trial and error".
After going back to my code I realized that defun was not performing any
magic, rather I passed the symbol function attribute which was then bound to
a symbol variable attribute.
Looking up 'funcall' in the HyperSpec revealed:
"funcall applies function to args. If function is a symbol, it is coerced to
a function as if by finding its functional value in the global environment."
Which is why funcall failed when I used (funcall #'...)
Finally, thank you, Mr. Pitman for such a detailed explanation on the
namespace issue. I'm sure your time is limited and I appreciate you spending
it by giving me such a thorough description. Your posting on Slashdot is the
reason I am trying to learn Lisp in the first place.
-Luke Crook
HD+ Associates
www.hd-plus.com
Erik Haugan
> I think if programming languages were to be compared to preparing a meal,
> then Lisp would be the old Italian chef who makes his pasta from scratch.
> Other languages seem more like the student who throws a TV dinner into the
> microwave. The chef might be slower but his guests will have a lot less
> indigestion after the fact.
Other food-makers may have more TV dinners in the freezer, but try to
instruct the student how to make the fresh pasta meal, and see who's
fastest then.
Steve Long
Erik Naggum wrote:
> But how did you manage to write this code in the first place? It is so
> odd to mess with the symbol-function slot of a symbol without knowing
> what #' means or how the macro lambda works.
I'm sorry to say that this use-ignorance relationship was very common in my
cubicle farm.