Hi!
Consider the following silly macro:
(defmacro mypairlis (x y)
`(sort (pairlis ,x ,y) #'< :key #'car))
(defun tst3 ()
(let ((l1 '(1 2 3))
(l2 '(9 8 7)))
(mypairlis l1 l2)))
(defun tst2 ()
(flet ((car (x)
(cdr x)))
(let ((l1 '(1 2 3))
(l2 '(9 8 7)))
(mypairlis l1 l2))))
(defun tst ()
(map nil #'pprint (list (tst2) (tst3))))
Obviously, the output of `tst' will be different if I had defined
pairlis as
(defmacro mypairlis (x y)
`(sort (pairlis ,x ,y) '< :key 'car))
and I'd actually prefer the latter behavior, because I guess that
most people only want to influence their own uses of `car' when
they redefine it locally. Redefining car isn't allowed, but you
get the point.
I am asking this because I keep wondering why people might use
'car as designator instead of #'car. I learned only very lately
that this is possible at all and never used it. I magically
overlooked that actually some examples in the HyperSpec use 'car,
too, IIRC. Then I saw that CAPI uses it all the time, and Kent
Pitman mentioned recently that he is at least afraid of #'car
because it might cons.
Maybe using 'car as designator has some merits:
(i) It's one less character to type.
(ii) I have unlearned it from Emacs Lisp, but at least there
once was a time when it seemed natural to me, and so
doesn't necessarily look as wrong as it looks to me now.
(iii) One might use #' to document ``Hey, a closure is being
built here!'' Will probably not work always.
(iv) The macro issue above.
But then, I still don't like looking at 'car very much. Maybe one
could get used to it, but I am also not sure if one /should/ get
used to it :-) So, I thought I'd ask people for opinions... Are
many people out there who use the 'car notation?
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0xC66D6E6F
> But then, I still don't like looking at 'car very much. Maybe one
> could get used to it, but I am also not sure if one /should/ get
> used to it :-) So, I thought I'd ask people for opinions... Are
> many people out there who use the 'car notation?
Not for car, but for other things, especially in my own functions
that are under active development, so I *want* the late binding affect.
Compilers especially tend to wire in the value of #'foo as a literal,
so if I later redefine foo I also have to recompile the functions that
use it.
Michael Parker <·······@pdq.net> writes:
> > But then, I still don't like looking at 'car very much. Maybe one
> > could get used to it, but I am also not sure if one /should/ get
> > used to it :-) So, I thought I'd ask people for opinions... Are
> > many people out there who use the 'car notation?
>
> Not for car, but for other things, especially in my own functions
> that are under active development, so I *want* the late binding affect.
> Compilers especially tend to wire in the value of #'foo as a literal,
> so if I later redefine foo I also have to recompile the functions that
> use it.
This is not a valid optimization.
The description of the FUNCTION special operator in the spec says it returns:
The value of function is the functional value of name in
the current lexical environment.
It _doesn't_ say "... in some environment that it was convenient or
'more efficient' to obtain at compile or load time."
NOTE that if you _execute_ the #' you will have frozen the value. That is,
(defvar *foo* #'foo)
at time of _execution_ gets the definition of FOO and subsequent redefinitions
of FOO can't affect *FOO* without reassigning *FOO* explicitly. For delayed
effect you want either 'foo or #'(lambda (&rest args) (apply #'foo args))
as the value of *foo*.
But the reason it is safe to use #'(lambda (&rest args) (apply #'foo args))
is to defer the meaning of #'foo to the time of each and every call to APPLY
done by that closure.
Kent M Pitman wrote:
>
> Michael Parker <·······@pdq.net> writes:
>
> > > But then, I still don't like looking at 'car very much. Maybe one
> > > could get used to it, but I am also not sure if one /should/ get
> > > used to it :-) So, I thought I'd ask people for opinions... Are
> > > many people out there who use the 'car notation?
> >
> > Not for car, but for other things, especially in my own functions
> > that are under active development, so I *want* the late binding affect.
> > Compilers especially tend to wire in the value of #'foo as a literal,
> > so if I later redefine foo I also have to recompile the functions that
> > use it.
>
> This is not a valid optimization.
This may not be a valid optimization, but I have seen more than one
compiler that definitely seemed to act like they were cacheing the
function value. I could be wrong -- after the first few times, I got
into the habit of just quoting non-system global functions. I never
really looked into it further.
> The description of the FUNCTION special operator in the spec says it returns:
>
> The value of function is the functional value of name in
> the current lexical environment.
>
> It _doesn't_ say "... in some environment that it was convenient or
> 'more efficient' to obtain at compile or load time."
>
> NOTE that if you _execute_ the #' you will have frozen the value. That is,
> (defvar *foo* #'foo)
Is it legal to cache the function value after the first hit?
> at time of _execution_ gets the definition of FOO and subsequent redefinitions
> of FOO can't affect *FOO* without reassigning *FOO* explicitly. For delayed
> effect you want either 'foo or #'(lambda (&rest args) (apply #'foo args))
> as the value of *foo*.
I'm aware that executing #' will indeed freeze the value. But I saw
this behavior in things like
(defun frob (list) (mapcar #'frobulator list))
where recompiling frobulator didn't change frob's behavior.
I'll have to go back and check my various lisp systems and
doublecheck. I'm *certain* I've seen this in GCL at high
optimization levels (maybe only for functions in the same
compilation unit, though), and given its eccentricities
it's an obvious suspect. Definitely *doesn't* happen in
LispWorks. I went back and checked the some my old code
from the Symbolics, and the only cases there that used '
were where I was stashing functions away somewhere like
a hashtable. So maybe this was all just a GCL-induced
wart :-)
Michael Parker <·······@pdq.net> writes:
> I'm aware that executing #' will indeed freeze the value. But I saw
> this behavior in things like
>
> (defun frob (list) (mapcar #'frobulator list))
>
> where recompiling frobulator didn't change frob's behavior.
If frobulator is eligible for inlining, and mapcar is
compiler-macroexpanded to something to the effect of
(loop for x in list collect (frobulator x))
then perhaps could the behavior you describe be considered conforming?
I guess my real question is, is a function for which no inline
declaration exists eligible for inlining by the compiler? From reading
the CLHS page on inline and notinline, I get the impression that to
make sure a function is not inlined, it must be declared notinline. Is
this the case?
--
Frode Vatvedt Fjeld
In article <··············@vserver.cs.uit.no>,
Frode Vatvedt Fjeld <······@acm.org> wrote:
>I guess my real question is, is a function for which no inline
>declaration exists eligible for inlining by the compiler? From reading
>the CLHS page on inline and notinline, I get the impression that to
>make sure a function is not inlined, it must be declared notinline. Is
>this the case?
Any functions defined by the CL standard are eligible for inlining by
default, and you must declare them NOTINLINE explicitly to prevent this.
This is what allows compilers to open-code low-level functions like CAR and
+, for instance.
User-defined functions are not eligible for inlining by default, and you
must explicitly declare them INLINE to allow it.
--
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.
Nils Goesche <···@cartan.de> writes:
> I keep wondering why people might use 'car as designator instead of
> #'car. [...] Then I saw that CAPI uses it all the time, [...]
There's a long-standing bug in LispWorks that FUNCTION doesn't pick up
the "encapsulations" of a function, which are a way to add extra code
to a function while managing the original definition separately.
Encapsulations are used to implement trace and advice, so funcalling
#'FOO will not show up in traces. Hence some people have started to
avoid it.
There's a view that this is a feature rather than a bug, but I forget
what the reasoning was.
--
Pekka P. Pirinen
A feature is a bug with seniority. - David Aldred <david_aldred.demon.co.uk>
"Pekka P. Pirinen" <···············@globalgraphics.com> wrote in message
··················@globalgraphics.com...
> Nils Goesche <···@cartan.de> writes:
> > I keep wondering why people might use 'car as designator instead of
> > #'car. [...] Then I saw that CAPI uses it all the time, [...]
>
> There's a long-standing bug in LispWorks that FUNCTION doesn't pick up
> the "encapsulations" of a function, which are a way to add extra code
> to a function while managing the original definition separately.
> Encapsulations are used to implement trace and advice, so funcalling
> #'FOO will not show up in traces. Hence some people have started to
> avoid it.
>
> There's a view that this is a feature rather than a bug, but I forget
> what the reasoning was.
IIRC, we decided that FUNCTION and SYMBOL-FUNCTION (also FDEFINITION now) should
behave in the same way for global function definitions. This makes forms like
these:
(setf (symbol-function 'foo) (symbol-function 'foo))
(setf (symbol-function 'foo) (symbol-function 'bar))
(rotatef (symbol-function 'foo) (symbol-function 'bar))
somewhat confusing if FOO and/or BAR have encapsulations (especially when you
try to remove them again).
The chosen solution was to make SYMBOL-FUNCTION and (SETF SYMBOL-FUNCTION)
operate on the underlying definition, so encapsulations always stick to the
function names, not the functions.
--
Martin Simmons, Xanalys Software Tools
······@xanalys.com
rot13 to reply
Can I just say, slightly out of contex, but not worth another thread I hope:
None of this discussion is about function designators.
That's not a comment on the content of the thread, just on the subject line.
Names are not the same as designators. Neither a FUNCTION form nor
the argument to such a form is a function designator.
Thanks for your attention. I feel better now.
References:
CLHS 1.4.1.5 Designators
See the glossary entry, too.
In article <···············@shell01.TheWorld.com>, Kent M Pitman wrote:
> Can I just say, slightly out of contex, but not worth another thread I hope:
>
> None of this discussion is about function designators.
> That's not a comment on the content of the thread, just on the subject line.
>
> Names are not the same as designators. Neither a FUNCTION form nor
> the argument to such a form is a function designator.
>
> Thanks for your attention. I feel better now.
>
> References:
> CLHS 1.4.1.5 Designators
> See the glossary entry, too.
I am confused :-) In CLHS 1.4.1.5 there is an example:
(defun add-some (x)
(defun add-some (x) (+ x 2))
(+ x 1)) => ADD-SOME
(mapcar 'add-some '(1 2 3 4))
The original question was why one might want to use 'add-some instead
of #'add-some. Is this not a question about function designators?
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche <······@cartan.de> writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman wrote:
> > Can I just say, slightly out of contex, but not worth another thread I hope:
> >
> > None of this discussion is about function designators.
> > That's not a comment on the content of the thread, just on the subject line.
> >
> > Names are not the same as designators. Neither a FUNCTION form nor
> > the argument to such a form is a function designator.
> >
> > Thanks for your attention. I feel better now.
> >
> > References:
> > CLHS 1.4.1.5 Designators
> > See the glossary entry, too.
>
> I am confused :-) In CLHS 1.4.1.5 there is an example:
>
> (defun add-some (x)
> (defun add-some (x) (+ x 2))
> (+ x 1)) => ADD-SOME
> (mapcar 'add-some '(1 2 3 4))
>
> The original question was why one might want to use 'add-some instead
> of #'add-some. Is this not a question about function designators?
#'add-some is not a function designator. It is a special form that returns
a function whose name is add-some in the lexical environment.
'add-some is a function designator, but it names a function in the global
environment.
Designators are objects, not pieces of program syntax. The only object
that comes into play when you do #'add-some is #<FUNCTION ...>, which _is_
a function designator because it is a function.
ADD-SOME, a symbol, can double as a function (i.e., is a function designator)
but it has no lexical environment attached so it designates the global value
of that symbol, not any lexical value. Otherwise, it would be meaningless
to pass as an arg, since functions cannot access each others' lexical
environments.
This is a reason I get annoyed when people use 'foo and #'foo in text
to refer to the objects that they name. THey should refer to "the symbol FOO"
and "the function FOO" because "the list (QUOTE FOO)" and
"the list (FUNCTION FOO)" are different things that they only by chance happen
not to be discussing at that instant. Because hte purpose of syntax is to
disambiguate in complex situations, it's a bad idea to indulge syntax which
creates ambiguity by meaning what it does not apepar to mean.
If your question is whether to use 'add-some, that is, the list (QUOTE
ADD-SOME) or #'add-some, that is, the list (FUNCTION ADD-SOME), then
your question is not about designators. If your question is whether
to pass the symbol ADD-SOME or a function #<FUNCTION ADD-SOME>, then
your question is about designators. But I did not, because of how you
phrased the question, understand this. You're crossing between terminology
intended to talk about dataflow and terminology intended to talk about syntax
as if they were the same. It's not that you're saying something that I
can't, now that you explain it, understand. But you have mixed metaphors
and incrased the likelihood of talking at crossed purposes.
For example, if you do
(let ((x (symbol-function 'foo)))
(flet ((foo () ...))
(funcall x ...)))
you are now asking about whether it's ok to pass #<FUNCTION ...> even
though only 'foo was used notationally. Using #'foo would not affect
the outcome in this case because there is no FLET of FOO intervening
between the call to symbol-function and the global environment. So this
is an exmaple where the use of correct terminology helps clarify which
of several questions you might be asking.
I'm not sure if you fell into any of these pits during the conversation,
which I largely have not been following. I just know it could because
the terminology looks sloppy in the messages I spot checked.
Sorry for being nitpicky...
In article <···············@shell01.TheWorld.com>, Kent M Pitman wrote:
> I'm not sure if you fell into any of these pits during the conversation,
> which I largely have not been following. I just know it could because
> the terminology looks sloppy in the messages I spot checked.
>
> Sorry for being nitpicky...
I am not sure if I had really understood the difference you are talking
about when I posted the question but I certainly am now. Thanks
very much!
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
···············@globalgraphics.com (Pekka P. Pirinen) writes:
> Nils Goesche <···@cartan.de> writes:
> > I keep wondering why people might use 'car as designator instead of
> > #'car. [...] Then I saw that CAPI uses it all the time, [...]
>
> There's a long-standing bug in LispWorks that FUNCTION doesn't pick up
> the "encapsulations" of a function, which are a way to add extra code
> to a function while managing the original definition separately.
> Encapsulations are used to implement trace and advice, so funcalling
> #'FOO will not show up in traces. Hence some people have started to
> avoid it.
>
> There's a view that this is a feature rather than a bug, but I forget
> what the reasoning was.
> --
> Pekka P. Pirinen
> A feature is a bug with seniority. - David Aldred <david_aldred.demon.co.uk>
You may have forgotten the reasoning, but your signature gives one
view of the answer. Another way to say it is that sometimes people
call a bug a feature when they don't know how to fix it.
We went for many years with encapsulations, still fighting the notion
that they were indeed broken, because it was all we had for an
otherwise very useful facility. One of the more interesting ways
encapsulations failed for us was to change what encapsulating a #'foo
method or gf would do to the result of (typep #'foo 'generic-function).
So we rebelled, and found a better solution. We call this solution
"fwrappers" (function wrappers) and it solves many problems that
encapsulations couldn't solve, which includes the fact that an
fwrapped function object always retains its identity and thus its
characteristics). We also reimplemented our trace facility to use
fwrappers instead of encapsulations. See
http://www.franz.com/support/documentation/6.1/doc/fwrappers-and-advice.htm#fwrap-intro-1
Another significant difference is with the defining operator,
def-fwrapper, which is a top-level defining macro in the spirit
of Common Lisp, rather than the forms-based defadvice/advise
definers for encapsulations. This allows extremely efficient
compilation, no need for compile or eval in the image in order
to wrap functions, transparency of the defining form through
macroexpansion, etc.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> ... Another significant difference is with the defining operator,
> def-fwrapper, ...
If this is some misguided Californian attempt to parody the East Coast
Lisp Machines' defwhopper [the grandfather of the CL "around method"]
but using frappes instead of burgers as the metaphorical basis, you
want def-frapper, not def-fwrapper.
For those who don't have "frappe" in their lexicon, it means in
Massachusetts what would be called "milkshake" anywhere else in
the US. If you order a "milkshake" (except at a national chain
restaurant like McD's, which is usually oblivious to local
dialectal issues) in the Boston area you just get flavored milk,
not milk with ice cream in it. Because of these dialectal problems,
though, I think frappes, however tasty, are a bad metaphor. Maybe
you should pick another.
Perhaps sandwich wraps? Then you could call it, say, def-wrapper.
Kent M Pitman <······@world.std.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > ... Another significant difference is with the defining operator,
> > def-fwrapper, ...
>
> If this is some misguided Californian attempt to parody the East Coast
> Lisp Machines' defwhopper [the grandfather of the CL "around method"]
> but using frappes instead of burgers as the metaphorical basis, you
> want def-frapper, not def-fwrapper.
No, no, no; we really attempted to be global in our naming; if we had
stuck with California terminology, we would have instead called
it def-fwrappucino (with the "def" being short for "decaffinated").
> For those who don't have "frappe" in their lexicon, it means in
> Massachusetts what would be called "milkshake" anywhere else in
> the US. If you order a "milkshake" (except at a national chain
> restaurant like McD's, which is usually oblivious to local
> dialectal issues) in the Boston area you just get flavored milk,
> not milk with ice cream in it. Because of these dialectal problems,
> though, I think frappes, however tasty, are a bad metaphor. Maybe
> you should pick another.
I also hate it when I go into a restaurant and order a malt, and
they give me a milkshake. I usually send it back, unless they
have told me beforehand that they didn't serve malts but they
do serve milshakes. I then order a milkshake happily.
> Perhaps sandwich wraps? Then you could call it, say, def-wrapper.
Perhaps, but a wrapper would give the sandwich a distinctively
plastic taste. I think not.
Anyway, The name is pronounced with three sylables; perhaps I
should have named it def-f-wrapper instead. I thought the
names function-wrapper and def-function-wrapper were too long.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
"Duane Rettig" <·····@franz.com> wrote in message
··················@beta.franz.com...
> Kent M Pitman <······@world.std.com> writes:
>
> > Perhaps sandwich wraps? Then you could call it, say, def-wrapper.
>
> Perhaps, but a wrapper would give the sandwich a distinctively
> plastic taste. I think not.
>
> Anyway, The name is pronounced with three sylables; perhaps I
> should have named it def-f-wrapper instead. I thought the
> names function-wrapper and def-function-wrapper were too long.
>
Better. I was having enough trouble keep def-rapper and
def-rock-n-roller straight. Throwing def-wrapper, etc. in the mix
is just too confusing. And I won't even mention def-leopard. :-)
Geoff
Duane Rettig <·····@franz.com> writes:
> Anyway, The name is pronounced with three sylables; perhaps I
> should have named it def-f-wrapper instead. I thought the
> names function-wrapper and def-function-wrapper were too long.
Not that I'm complaining too loudly (or, indeed, at all), but note
that both def-fwrapper and def-f-wrapper break an implicit CL naming
convention: that defining forms begin "def[^-]" in unhyphenated
symbols (examples: defun, defmacro, defmethod, ...) and "define-" when
the rest is hyphenated (define-symbol-macro, define-setf-expander,
...)
I grant you that deffwrapper might get misspelt rather too often, and
define-function-wrapper tend to induce RSI...
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
In article <··············@cam.ac.uk>,
Christophe Rhodes <·····@cam.ac.uk> wrote:
>
>Not that I'm complaining too loudly (or, indeed, at all), but note
>that both def-fwrapper and def-f-wrapper break an implicit CL naming
>convention: that defining forms begin "def[^-]" in unhyphenated
>symbols (examples: defun, defmacro, defmethod, ...) and "define-" when
>the rest is hyphenated (define-symbol-macro, define-setf-expander,
>...)
What is this "un" that a "defun" defines? :-)
--d
Christophe Rhodes <·····@cam.ac.uk> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Anyway, The name is pronounced with three sylables; perhaps I
> > should have named it def-f-wrapper instead. I thought the
> > names function-wrapper and def-function-wrapper were too long.
>
> Not that I'm complaining too loudly (or, indeed, at all), but note
> that both def-fwrapper and def-f-wrapper break an implicit CL naming
> convention: that defining forms begin "def[^-]" in unhyphenated
> symbols (examples: defun, defmacro, defmethod, ...) and "define-" when
> the rest is hyphenated (define-symbol-macro, define-setf-expander,
> ...)
I personally rather prefer it that way. It makes it easy in code
written for Allegro CL to tell which defining forms are standard,
and which are extensions.
We don't always follow this tendency, and I don't actually view
it as a convention at all, but you might note that we make this
separation of our own defining forms from CL defining forms more
often than not:
http://www.franz.com/support/documentation/6.1/doc/nocg-index-d.htm
but I don't think we've conciously thought much about it; we just
try to select the names that feel like the right names. And those
names aren't randomly picked by a single developer; if someone
objects to a particular name they certainly voice that objection,
many times resulting in a name change.
> I grant you that deffwrapper might get misspelt rather too often, and
> define-function-wrapper tend to induce RSI...
Well, there you have it...
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Anyway, The name is pronounced with three sylables; perhaps I
> should have named it def-f-wrapper instead. I thought the
> names function-wrapper and def-function-wrapper were too long.
Sorry; I wasn't clear here; it is the last word in def-fwrapper that
has three sylables, not the whole word (which has 4, of course).
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)