Hi all,
Here is the most simplistic code to demonstrate my
problem:
;;;;;;;;;;;;;;;
(defstruct foo
action)
(defun fooact (x)
(+ 1 v))
(setf fred (make-foo :action #'fooact))
(format t "action is ~A;~%" (foo-action fred))
;;;;;;;;;;;;;;
I want to display "fooact" (the _name_ of the action function of fred),
but the format above displays:
#<CLOSURE FOOACT (X) (DECLARE (IN-DEFUN FOOACT)) (BLOCK FOOACT (+ 1 V))>
In my CLISP 2.28
How can I display "fooact" in such a case, assuming that I know
that it is a function.
Thanks in advance
Eli
--
Email: ________ at yahoo dot com
(the username is spur4444)
Website: http://www.geocities.com/spur4444/
On Wed, Nov 20, 2002 at 06:51:06PM +0200, Eli Bendersky wrote:
> (defstruct foo
> action)
>
> (defun fooact (x)
> (+ 1 v))
>
> (setf fred (make-foo :action #'fooact))
>
> (format t "action is ~A;~%" (foo-action fred))
[...]
> How can I display "fooact" in such a case, assuming that I know
> that it is a function.
What if it is:
(setf fred (make-foo :action #'(lambda (x) (1+ x))))
?
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Frode Vatvedt Fjeld
Subject: Re: Printing a name of function (closure ?) with format
Date:
Message-ID: <2h8yzo6okc.fsf@vserver.cs.uit.no>
Eli Bendersky <··@the.signature> writes:
> How can I display "fooact" in such a case, assuming that I know that
> it is a function.
In general, functions don't have names. So you can't, within the
limits of ANSI CL. But most implementations do associate a name with
function objects for debugging purposes. I don't know about clisp,
though.
You could do this:
(setf fred (make-foo :action 'fooact))
and probably it would behave the same, only you'd have no problems
with the printing.
Symbols with function-values are funcallable just like function
objects are. The difference between using #'fooact and 'fooact, is the
time at which the binding between the name and the function is
captured.
--
Frode Vatvedt Fjeld
From: Nils Goesche
Subject: Re: Printing a name of function (closure ?) with format
Date:
Message-ID: <lku1icujre.fsf@cartan.de>
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Symbols with function-values are funcallable just like function
> objects are. The difference between using #'fooact and 'fooact, is
> the time at which the binding between the name and the function is
> captured.
Especially, #'fooact will first check the lexical environment and only
then the global environment.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Eli Bendersky <··@the.signature> writes:
>
> > How can I display "fooact" in such a case, assuming that I know that
> > it is a function.
>
> In general, functions don't have names. So you can't, within the
> limits of ANSI CL. But most implementations do associate a name with
> function objects for debugging purposes. I don't know about clisp,
> though.
>
> You could do this:
>
> (setf fred (make-foo :action 'fooact))
>
> and probably it would behave the same, only you'd have no problems
> with the printing.
>
> Symbols with function-values are funcallable just like function
> objects are. The difference between using #'fooact and 'fooact, is the
> time at which the binding between the name and the function is
> captured.
This works, thanks. Could you please elaborate on the difference between
this and #' ? When creating my foo's with :action 'fooact, do I introduce
some un-portability ?
--
Email: ________ at yahoo dot com
(the username is spur4444)
Website: http://www.geocities.com/spur4444/
From: Frode Vatvedt Fjeld
Subject: Re: Printing a name of function (closure ?) with format
Date:
Message-ID: <2h4rab6xho.fsf@vserver.cs.uit.no>
Eli Bendersky <··@the.signature> writes:
> Could you please elaborate on the difference between this and #' ?
> When creating my foo's with :action 'fooact, do I introduce some
> un-portability ?
Funcallable symbols are very much a part of the standard.
Think of the function namespace as a mapping from symbols to
functions. When #'foo is evaluated, it looks up foo in this namespace
(modulo any intervening lexical bindings). So if this mapping is
changed (by you redefining foo, for example), this will not be
magically noticed by the slot that previously received the result of
#'foo. On the other hand, if you funcall the symbol foo, the mapping
is reexamined at every call, just like it is for normal function
calls.
What I think this all amounts to, is the following advise: Don't just
blindly use the function operator (i.e. #') whenever you do something
function-related. It should only be used when you actually need to
capture some aspect of the lexical environment. When you refer to
normal functions defined by defun, the right thing is almost always to
use the symbol.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Eli Bendersky <··@the.signature> writes:
>
> > Could you please elaborate on the difference between this and #' ?
> > When creating my foo's with :action 'fooact, do I introduce some
> > un-portability ?
>
> Funcallable symbols are very much a part of the standard.
>
> Think of the function namespace as a mapping from symbols to
> functions. When #'foo is evaluated, it looks up foo in this namespace
> (modulo any intervening lexical bindings). So if this mapping is
> changed (by you redefining foo, for example), this will not be
> magically noticed by the slot that previously received the result of
> #'foo. On the other hand, if you funcall the symbol foo, the mapping
> is reexamined at every call, just like it is for normal function
> calls.
>
> What I think this all amounts to, is the following advise: Don't just
> blindly use the function operator (i.e. #') whenever you do something
> function-related. It should only be used when you actually need to
> capture some aspect of the lexical environment. When you refer to
> normal functions defined by defun, the right thing is almost always to
> use the symbol.
What _I_ think this amounts to is the following advice: Don't just
blindly use the QUOTE operator (i.e. ') whenever you do something
function-related. It should only be used when you actually need to
capture some aspect of the global environment. When you refer to
normal functions defined in the lexical environment, the right thing
is almost always to use the function cell.
From: Frode Vatvedt Fjeld
Subject: Re: Printing a name of function (closure ?) with format
Date:
Message-ID: <2hptsy5bb8.fsf@vserver.cs.uit.no>
Kent M Pitman <······@world.std.com> writes:
> What _I_ think this amounts to is the following advice: Don't just
> blindly use the QUOTE operator (i.e. ') whenever you do something
> function-related. It should only be used when you actually need to
> capture some aspect of the global environment. When you refer to
> normal functions defined in the lexical environment, the right thing
> is almost always to use the function cell.
While don't I disagree with any of this, it leaves me somewhat
puzzled. I've never seen myself or others thoughtlessly using quote to
refer to functions. But it does seem to me that a lot of people as one
of their earliest lisp experiences pick up some fuzzy notion that one
must use the function operator whenever they refer to a function, and
never quite get around to understanding what this operator actually
does and when it should be used.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > What _I_ think this amounts to is the following advice: Don't just
> > blindly use the QUOTE operator (i.e. ') whenever you do something
> > function-related. It should only be used when you actually need to
> > capture some aspect of the global environment. When you refer to
> > normal functions defined in the lexical environment, the right thing
> > is almost always to use the function cell.
>
> While don't I disagree with any of this, it leaves me somewhat
> puzzled. I've never seen myself or others thoughtlessly using quote to
> refer to functions. But it does seem to me that a lot of people as one
> of their earliest lisp experiences pick up some fuzzy notion that one
> must use the function operator whenever they refer to a function, and
> never quite get around to understanding what this operator actually
> does and when it should be used.
Using QUOTE is referring to the introspective layer of CL and is overkill
for most common programming applications.
I think, too, that it reflects an improper fear that good macro hygiene
needs to protect itself from an unexpected FLET, even though proper use
of the package system means this should never really happen.
I also think there are compilers that compile (apply 'foo ...) and
(apply #'foo ...) differently even where there are no intervening flet
bindings, and this leads to a superstition on the user's part that the
language forces a distinction that in fact it does not.
You're right, of course, that sometimes people don't learn to use all
the introspective tools they could, but I think it's a very bad plan
to use QUOTE by preference when confronted with the choice of two ways
to do things. It's like saying people should put things on property
lists instead of using toplevel lexical variables because otherwise
people won't learn about properties... There are right and wrong ways
to learn things.
"Eli Bendersky" <··@the.signature> wrote in message
····················@lnx-baruch.haifa.ibm.com...
> Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> > Symbols with function-values are funcallable just like function
> > objects are. The difference between using #'fooact and 'fooact, is the
> > time at which the binding between the name and the function is
> > captured.
>
> This works, thanks. Could you please elaborate on the difference between
> this and #' ? When creating my foo's with :action 'fooact, do I introduce
> some un-portability ?
I'm sure this is a fine solution for you, given that you really are
interested in the function by name. The difference will be only this: with
#'fooact, the function object is captured when the slot is bound and thus
will not be redefinable without resetting the slot. Unless you are
modifying code and rewriting functions at runtime, you probably don't care.
If you do care, you just need to decide whether you want the slot to be
unchanged upon redefinition or not. Using 'fooact, you will get whichever
function object is currently that symbol's symbol-function. This may be a
big advantage in development when you will be changing function definitions
etc.
I have found with LispWorks that if you use #'fooact and then (trace fooact)
you will not see calls made from your action slot, that may be inconvenient
for you as well.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> If you do care, you just need to decide whether you want the slot to be
> unchanged upon redefinition or not. Using 'fooact, you will get whichever
> function object is currently that symbol's symbol-function. This may be a
> big advantage in development when you will be changing function definitions
> etc.
This should not matter in a lot of situations where the function is used
directly. e.g., there should NEVER, in my opinion, be an observable
operational distinction between
(apply 'foo x)
and
(apply #'foo x)
unless FOO is lexically bound.
> I have found with LispWorks that if you use #'fooact and then (trace fooact)
> you will not see calls made from your action slot, that may be inconvenient
> for you as well.
I've been back and forth with the Xanalys team a lot on this and I don't
like their formulation of this. I've never taken the time to figure out
if it can really be the case that what they're doing is truly conforming,
but I know it violates my intuitions really a lot and drives me nuts.
Whether it's not conforming or simply not my first choie of several possible
conforming ways to do it, it's still on my list of top 10 annoyances with
the LispWorks implementation (which I mostly like quite a lot, btw--but I
still have occasional gripes with :) ...
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
> > If you do care, you just need to decide whether you want the slot to be
> > unchanged upon redefinition or not. Using 'fooact, you will get
whichever
> > function object is currently that symbol's symbol-function. This may be
a
> > big advantage in development when you will be changing function
definitions
> > etc.
>
> This should not matter in a lot of situations where the function is used
> directly. e.g., there should NEVER, in my opinion, be an observable
> operational distinction between
> (apply 'foo x)
> and
> (apply #'foo x)
> unless FOO is lexically bound.
Indeed, it becomes only a matter of style choice and I think that discussion
has been here before many times, my personal preference being for #' as it
is more representative of what you really want, ie the symbol-function not
just the symbol.
But back to the OP's original situation the difference is more significant:
CL-USER 9 > (defstruct foo action)
FOO
CL-USER 10 > (defun fooact (arg) (+ 2 arg))
FOOACT
CL-USER 11 > (setf f1 (make-foo :action #'fooact))
#S(FOO ACTION #'(LAMBDA (ARG) (DECLARE (LAMBDA-NAME FOOACT)) (BLOCK FOOACT
(+ 2 ARG))))
CL-USER 12 > (setf f2 (make-foo :action 'fooact))
#S(FOO ACTION FOOACT)
CL-USER 13 > (values (funcall (foo-action f1) 5)
(funcall (foo-action f2) 5))
7
7
CL-USER 14 > (defun fooact (arg) (* 2 arg))
FOOACT
CL-USER 15 > (values (funcall (foo-action f1) 5)
(funcall (foo-action f2) 5))
7
10
;; also, what if you want to create the object before
;; you have loaded or written the function?
CL-USER 16 > (make-foo :action #'not-done-yet)
Error: Undefined function NOT-DONE-YET in form (SYMBOL-FUNCTION
NOT-DONE-YET).
1 (continue) Take the function definition of another function name.
2 Try to take the function definition of NOT-DONE-YET again.
3 Return a value from the call to (SYMBOL-FUNCTION NOT-DONE-YET).
4 Set the function definition of NOT-DONE-YET to another function.
5 (abort) Return to level 0.
6 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or :? for other
options
> > I have found with LispWorks that if you use #'fooact and then (trace
fooact)
> > you will not see calls made from your action slot, that may be
inconvenient
> > for you as well.
>
> I've been back and forth with the Xanalys team a lot on this and I don't
> like their formulation of this. I've never taken the time to figure out
> if it can really be the case that what they're doing is truly conforming,
> but I know it violates my intuitions really a lot and drives me nuts.
It is definitely anti-intuitive for me too. I remember having this same
exchange with you when I got bit by that about a year and a half ago. I was
going to write that now I know, it won't fool me again...but I can't say I
use (mapcar 'my-func data) any more often than I ever did. We'll just see
how quickly I figure it out next time!
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
From: Pascal Costanza
Subject: Re: Printing a name of function (closure ?) with format
Date:
Message-ID: <3DDE1201.10305@web.de>
Coby Beck wrote:
> Indeed, it becomes only a matter of style choice and I think that discussion
> has been here before many times, my personal preference being for #' as it
> is more representative of what you really want, ie the symbol-function not
> just the symbol.
BTW, what do people think about (lambda (...) ...) vs. #'(lambda (...)
...) ?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> wrote in message news:<··············@web.de>...
>
> BTW, what do people think about (lambda (...) ...) vs. #'(lambda (...)
> ...) ?
>
My personal preference is:
#'(lambda ...) when passing a closure to a function as an argument, such as
(foo :test #'(lambda (x) (if (bar x) 't 'nil))) or even
(mapcar #'(lambda ...) lists)
and
(lambda ...) when it is used as a function, as in
(defstruct (foo
(:print-function
(lambda (o s d) ...)))
...)
Thanks,
Vijay L
From: Joe Marshall
Subject: Re: Printing a name of function (closure ?) with format
Date:
Message-ID: <8yzl65qg.fsf@ccs.neu.edu>
Pascal Costanza <········@web.de> writes:
> BTW, what do people think about (lambda (...) ...) vs. #'(lambda (...)
> ...) ?
I used to always write #'(lambda ...
but now I almost always write (lambda ...
Since they mean (virtually) the same thing, the version without the #'
saves some typing, avoids the shift key, and saves two columns for
indentation.
Joe Marshall <···@ccs.neu.edu> writes:
> Pascal Costanza <········@web.de> writes:
>
> > BTW, what do people think about (lambda (...) ...) vs. #'(lambda (...)
> > ...) ?
>
> I used to always write #'(lambda ...
> but now I almost always write (lambda ...
>
> Since they mean (virtually) the same thing, the version without the #'
> saves some typing, avoids the shift key, and saves two columns for
> indentation.
I prefer #'(lambda ...) because it's the primitive notation.
I like seeing the "#'" to remind me that a function is potentially
being consed. When I see (lambda ...) without #' I usually assume
it's a situation like ((lambda ...) ...) where the closure is not
actually being consed.
But in any case, this is purely an issue of syntactic preference, not
related to the ' vs #' thing for symbols. (lambda (...) ...) MEANS
PRECISELY #'(lambda (...) ...) and therefore can be used interchangeably
from an operational point of view. There is a semantic difference between
'foo and #'foo.
It used to be possible to sometimes use '(lambda (...) ...) in place of
#'(lambda (...) ...) but I never advised doing that because, as with symbols,
it occluded the local lexical environment and was an invitation to
referential confusion. It was both for this reason, and for reasons of
application delivery size that may or may not be obvious, that we removed
the ability to do this.
From: Pascal Costanza
Subject: Re: Printing a name of function (closure ?) with format
Date:
Message-ID: <3DDE52FA.9060106@web.de>
Kent M Pitman wrote:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>
>>Pascal Costanza <········@web.de> writes:
>>
>>
>>>BTW, what do people think about (lambda (...) ...) vs. #'(lambda (...)
>>>...) ?
>>
>>I used to always write #'(lambda ...
>>but now I almost always write (lambda ...
>>
>>Since they mean (virtually) the same thing, the version without the #'
>>saves some typing, avoids the shift key, and saves two columns for
>>indentation.
>
>
> I prefer #'(lambda ...) because it's the primitive notation.
> I like seeing the "#'" to remind me that a function is potentially
> being consed. When I see (lambda ...) without #' I usually assume
> it's a situation like ((lambda ...) ...) where the closure is not
> actually being consed.
I am sorry, but I don't understand this at all. What does it mean that a
"function is potentially being consed"? (Where in the spec would I look
that up?)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
In article <················@web.de>, Pascal Costanza <········@web.de> wrote:
> Kent M Pitman wrote:
> > I prefer #'(lambda ...) because it's the primitive notation.
> > I like seeing the "#'" to remind me that a function is potentially
> > being consed. When I see (lambda ...) without #' I usually assume
> > it's a situation like ((lambda ...) ...) where the closure is not
> > actually being consed.
>
> I am sorry, but I don't understand this at all. What does it mean that a
> "function is potentially being consed"? (Where in the spec would I look
> that up?)
It's not in the spec, it's a piece of knowledge about implementations,
though if you think about it it's not hard to figure out on your own that:
(defun foo (x) (lambda (y) (+ x y)))
consumes memory when FOO is called, since the closed-over value of X has
to be stored somewhere.
FWIW, I don't see why #'(lambda ... is a better indication of potential
function-consing than (lambda ... Personally, I use:
(defmacro fn (args &body body) `#'(lambda ,args ,@body))
E.
From: Nils Goesche
Subject: Re: Printing a name of function (closure ?) with format
Date:
Message-ID: <lkadk1sf79.fsf@cartan.de>
···@jpl.nasa.gov (Erann Gat) writes:
> FWIW, I don't see why #'(lambda ... is a better indication of
> potential function-consing than (lambda ...
I am not sure, but weren't there earlier dialects where you had the
choice of using LAMBDA /without/ building a closure /and/ the option
of wrapping the lambda expression into FUNCTION to build a closure
explicitly? Then, #' would indeed be a warning sign: ``Beware:
closure being built!��
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Nils Goesche <······@cartan.de> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > FWIW, I don't see why #'(lambda ... is a better indication of
> > potential function-consing than (lambda ...
>
> I am not sure, but weren't there earlier dialects where you had the
> choice of using LAMBDA /without/ building a closure /and/ the option
> of wrapping the lambda expression into FUNCTION to build a closure
> explicitly? Then, #' would indeed be a warning sign: ``Beware:
> closure being built!��
In early Lisp, you programmed a lot using naked lambdas. That is,
instead of (let ((x 3) (y 4)) (+ x y)) you wrote:
((lambda (x y) (+ x y))
3
4)
My eye is used to seeing an unmarked lambda as being an "immediate use"
lambda and looks for #'(lambda (x y) ...) as meaning "i plan to use this
as an object so i'm picking it up and offering it to someone else". in that
case, i always have to check for consing, which I don't have to in the
lambda combination case, ((lambda ...) ...). I like the #' notation because
it makes it easy to spot lambda qua object rather than lambda qua syntax.
I didn't say that others have to do the same thing. But style rules are
such that they are best if people adopt rules that they personally use
consistently, and people's code is best read if if they understand the
rationale for when people use code.
Likewise, when I see (foo x) I don't think "the FOO function is needed as
an object" but when I see #'foo, I am reminded that FOO is being lifted from
its home and used elsehwere. In fact, I think the spec does not prohibit
consing in this case and there may even have been some implementations
which have to do some demand-consing in this case, I'm not sure, in order to
avoid consing function cells for large numbers of symbols and only doing it
for the few that are ever used as objects. But again, I prefer to know when
a named function is being used as an object not just because of the issue
of side-effect but also because of the related issue of identity. Any
attempt to pull a function out of its cell means a potential that if the
name is updated subsequently while I'm holding the extracted copy, I'll
have a stale copy. So seeing #'foo calls my attention visually to the fact
that I am grabbing a "snapshot of FOO".
In article <··············@cartan.de>, Nils Goesche <······@cartan.de> wrote:
>···@jpl.nasa.gov (Erann Gat) writes:
>
>> FWIW, I don't see why #'(lambda ... is a better indication of
>> potential function-consing than (lambda ...
>
>I am not sure, but weren't there earlier dialects where you had the
>choice of using LAMBDA /without/ building a closure /and/ the option
>of wrapping the lambda expression into FUNCTION to build a closure
>explicitly? Then, #' would indeed be a warning sign: ``Beware:
>closure being built!��
In Maclisp, you had the choice of #'(lambda ...) or '(lambda ...), and only
the former would create a closure (however, only downward closures were
supported, not upward closures as in Scheme and CL, so closures didn't need
to cons). This also should make it clear how the read-macro for FUNCTION
was chosen.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> In article <··············@cartan.de>, Nils Goesche <······@cartan.de> wrote:
> >···@jpl.nasa.gov (Erann Gat) writes:
> >
> >> FWIW, I don't see why #'(lambda ... is a better indication of
> >> potential function-consing than (lambda ...
> >
> >I am not sure, but weren't there earlier dialects where you had the
> >choice of using LAMBDA /without/ building a closure /and/ the option
> >of wrapping the lambda expression into FUNCTION to build a closure
> >explicitly? Then, #' would indeed be a warning sign: ``Beware:
> >closure being built!��
>
> In Maclisp, you had the choice of #'(lambda ...) or '(lambda ...), and only
> the former would create a closure (however, only downward closures were
> supported, not upward closures as in Scheme and CL, so closures didn't need
> to cons). This also should make it clear how the read-macro for FUNCTION
> was chosen.
Actually, Maclisp didn't really make any effort to package a downward closure
it just assumed you'd make the function so that it didn't matter if it was
upward or downward.
There was an operator called *FUNCTION which was like FUNCTION except it
would return the cons [literally, not just figuratively] of the form
(FUNARG function . stack-pointer)
which could be used in a function-like way. Such a "function" could be
passed down (but NOT up) in order to be used to access the environment
at the right point on the stack.
These examples are from the Revised Maclisp Manual (the Pitmanual):
(DEFUN FOO (F X) (LIST X (FUNCALL F X))) => FOO
(DEFUN BAR (Y) (+ X Y)) => BAR
(SETQ X 5) => 5
(FOO ( FUNCTION BAR) 2) => (2 4)
(FOO (*FUNCTION BAR) 2) => (2 7)
(FOO (PROG (A B C) (RETURN ( FUNCTION BAR))) 2) => (2 4)
(FOO (PROG (A B C) (RETURN (*FUNCTION BAR))) 2) => error!
In case it's not obvious, this was a serious kludge. I mention it only
for the sake of clarifying the Maclisp history, not for the sake of saying
that Maclisp was doing anything even vaguely like the right thing...
It took CL to clean all this junk up.
Pascal Costanza <········@web.de> writes:
> Kent M Pitman wrote:
> > Joe Marshall <···@ccs.neu.edu> writes:
> >
> >>Pascal Costanza <········@web.de> writes:
> >>
> >>
> >>>BTW, what do people think about (lambda (...) ...) vs. #'(lambda (...)
> >>>...) ?
> >>
> >>I used to always write #'(lambda ...
> >>but now I almost always write (lambda ...
> >>
> >>Since they mean (virtually) the same thing, the version without the #'
> >>saves some typing, avoids the shift key, and saves two columns for
> >>indentation.
> > I prefer #'(lambda ...) because it's the primitive notation.
> > I like seeing the "#'" to remind me that a function is potentially
> > being consed. When I see (lambda ...) without #' I usually assume
> > it's a situation like ((lambda ...) ...) where the closure is not
> > actually being consed.
>
> I am sorry, but I don't understand this at all. What does it mean that
> a "function is potentially being consed"? (Where in the spec would I
> look that up?)
The spec is not a tutorial document, and never mentions storage allocation
so you won't find it. It's a fact of implementations, and it's something
you have to learn elsewhere.
(funcall (let ((x 3) (y 4))
(lambda () (+ x y))))
is logically the same as:
(funcall (lambda (env) (+ (car env) (cdr env)))
(let ((x 3) (y 4))
(cons x y)))
Note by contrast that
(lambda (x y) (+ x y))
does not have free variables and so executing it does not cons because
no values need to be "remembered".
That is, there are two parts to a closure:
(1) the code ... i.e., the "thing to do"
this is statically known at compile time
(2) the data to do it on.
this is statically known at compile time if there are no
free variables. otherwise, this involves some consing of a
data structure each time you "create a closure".
a closure is little more, internally, than
( #<function stuff-to-do> . <data-to-do-it-on> )
plus some fancy type tag information so it's not seen as a cons
but as a closure.
A closure that does not contain free references doesn't need this
extra cons wrapper and so is more primitive than the one that does,
even though the language doesn't make a different "type" (or "class")
for such a thing.
From: Tim Bradshaw
Subject: Re: Printing a name of function (closure ?) with format
Date:
Message-ID: <ey31y5da5jw.fsf@cley.com>
* Pascal Costanza wrote:
> I am sorry, but I don't understand this at all. What does it mean that
> a "function is potentially being consed"? (Where in the spec would I
> look that up?)
I think the canonical case is:
(defun foo (x)
#'(lambda (y)
(+ y x)))
This `has to' cons because it needs to capture the binding of X.
--tim
From: Nils Goesche
Subject: Re: Printing a name of function (closure ?) with format
Date:
Message-ID: <lkel9dsgkr.fsf@cartan.de>
Pascal Costanza <········@web.de> writes:
> Kent M Pitman wrote:
> > I prefer #'(lambda ...) because it's the primitive notation. I
> > like seeing the "#'" to remind me that a function is potentially
> > being consed. When I see (lambda ...) without #' I usually assume
> > it's a situation like ((lambda ...) ...) where the closure is not
> > actually being consed.
> I am sorry, but I don't understand this at all. What does it mean
> that a "function is potentially being consed"? (Where in the spec
> would I look that up?)
It doesn't belong into the spec because it is about the
implementation, not semantics. If the lambda expression contains free
variables, a closure is built and the captured bindings have to be
stored /somewhere/. There is no need to do that, however, if you use
the ((lambda ...) ...) form, because the function object is not passed
around (and possibly stored) anywhere. You could, for instance,
rewrite it like this:
((lambda (x y) (foo x y z)) a b) -> (let ((x a) (y b)) (foo x y z))
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Eli Bendersky <··@the.signature> writes:
> How can I display "fooact" in such a case, assuming that I know
> that it is a function.
[5]> (nth-value 2 (function-lambda-expression (foo-action fred)))
FOOACT
The standard does not guarantee this will work; however, if CLISP
can display the name in #<CLOSURE FOOACT ...>, it would be silly
not to let you read it with FUNCTION-LAMBDA-EXPRESSION as well.
From: Thomas A. Russ
Subject: Re: Printing a name of function (closure ?) with format
Date:
Message-ID: <ymi8yznahrt.fsf@sevak.isi.edu>
Kalle Olavi Niemitalo <···@iki.fi> writes:
>
> Eli Bendersky <··@the.signature> writes:
>
> > How can I display "fooact" in such a case, assuming that I know
> > that it is a function.
>
> [5]> (nth-value 2 (function-lambda-expression (foo-action fred)))
> FOOACT
>
> The standard does not guarantee this will work; however, if CLISP
> can display the name in #<CLOSURE FOOACT ...>, it would be silly
> not to let you read it with FUNCTION-LAMBDA-EXPRESSION as well.
Except that the name in the closure could come from somewhere else.
It is a lot less information that needs to be remembered (a pointer
to an existing symbol) than keeping the entire function definition
around.
Since FUNCTION-LAMBDA-EXPRESSION isn't guaranteed to have a value,
this will not necessarily work.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
···@sevak.isi.edu (Thomas A. Russ) writes:
> Except that the name in the closure could come from somewhere else.
> It is a lot less information that needs to be remembered (a pointer
> to an existing symbol) than keeping the entire function definition
> around.
If the Lisp implementation preserves only the name and not the
lambda expression, then FUNCTION-LAMBDA-EXPRESSION can return NIL
as the primary value and the name as the tertiary value.
In CLISP 2.30, FUNCTION-LAMBDA-EXPRESSION returns NIL T NIL for
compiled functions, but the printer still shows the name in
#<COMPILED-CLOSURE FOOACT>, and it can be read with
SYSTEM::CLOSURE-NAME. I do think this is silly.