Okay, I'm having a little difficulty understand when to use ' or #' and am
hoping someone can lend a simple example.
I understand that QUOTE returns the symbol (or whatever is quoted) and
FUNCTION returns the actual function. However, I can't seem to get either
to work on a test sample that I'm trying in order to clear up the
difference in my mind.
I'm trying this:
((if t + -) 1 2) ; doesn't work
((if t '+ '-) 1 2) ; doesn't work
((if t #'+ #'-) 1 2) ; doesn't work
Why do none of these work? If #' is the correct version (and I'm just doing
something wrong) then what is the difference between #'+ and just +?
Thanks in advance!
--
Best regards,
Jeff ··········@mfire.com
http://www.simforth.com
Jeff Massung <···@NOSPAM.mfire.com> writes:
> Okay, I'm having a little difficulty understand when to use ' or #' and am
> hoping someone can lend a simple example.
>
> I understand that QUOTE returns the symbol (or whatever is quoted) and
> FUNCTION returns the actual function. However, I can't seem to get either
> to work on a test sample that I'm trying in order to clear up the
> difference in my mind.
>
> I'm trying this:
>
> ((if t + -) 1 2) ; doesn't work
> ((if t '+ '-) 1 2) ; doesn't work
> ((if t #'+ #'-) 1 2) ; doesn't work
>
> Why do none of these work? If #' is the correct version (and I'm just doing
> something wrong) then what is the difference between #'+ and just +?
As Barry pointed out, you cannot put an arbitrary expression in the
function position of a form, so you need to put FUNCALL there.
In your code, an identifier (a name you type, like FOO) is either in
the function position (first element) or in an argument position. If
it is the function position, it is either
a) a lexically bound function or macro
created with FLET, LABELS, or MACROLET
or, if there is no lexical binding,
b) a `free' function
if it isn't in the function position, it is either
c) a lexically bound variable or macro
created with LET, LAMBDA, SYMBOL-MACROLET,
DO, DOTIMES, etc. etc. etc.
or, if there is no lexical binding,
d) a free variable
So in your first example (with funcalls added):
(funcall (if t + -) 1 2)
The identifiers + and - are free variables. The evaluation rule for
free variables is to look in the value cell of the corresponding
symbol. There is probably nothing in the value cell of either symbol,
so an unbound variable error is raised.
Since you were probably interested in the *functions* + and -, you
probably would like to apply rule A or B rather than rule C or D. You
use the FUNCTION special form to override the default:
(funcall (if t (function +) (function -)) 1 2)
In this case, you wish + and - to be free *functions*, not free
variables. The evaluation rule for free functions is to look in the
function cell of the corresponding symbol. This contains the function
you want, and the right thing happens. Note that this is equivalent
to typing (funcall (if t #'+ #'-) 1 2)
In the third example, instead of passing the addition or subtraction
function, you are passing a symbol. A symbol is a little structure
with a name and some cells associated with it. In general, you can't
apply structures to arguments, but there is a special case made for
symbols. If you try to apply a symbol to some arguments, the system
fetches what's in the function cell of the symbol and applies *that*
instead. So the effect is *similar* to the previous one, but not
identical. Consider this:
(let ((foo "I am foo"))
(flet ((foo (x) (+ x 42)))
(funcall #'foo 11))) => 53
(let ((foo "I am foo"))
(flet ((foo (x) (+ x 42)))
(funcall foo 11))) => error, can't apply a string
(let ((foo "I am foo"))
(flet ((foo (x) (+ x 42)))
(funcall 'foo 11))) => error, symbol foo has no function
binding
This last one may seem a bit confusing, after all there is a lexical
function binding right there! (and the first example works)
FLET establishes a function binding for the identifier foo, but that
has nothing to do with the little struct that is the symbol foo. The
little struct is untouched. But 'foo refers to the *symbol* foo ---
that little struct. So when funcall gets called, it gets handed a
symbol. It knows this is a special case and looks in the function
cell of the symbol. There's nothing there, so this is an error.
The first example works because writing #'foo (which is the same as
writing (FUNCTION foo)) tells the compiler that you want to treat the
name foo as a function, not a variable. There is a lexically visible
function name bound by the FLET, so that is #'foo means. The *symbol*
foo (our little struct) has no role in this interaction.
I hope this helps.
Joe Marshall <···@ccs.neu.edu> wrote in ·················@ccs.neu.edu:
> Jeff Massung <···@NOSPAM.mfire.com> writes:
>
[great explanation clipped]
>
> (let ((foo "I am foo"))
> (flet ((foo (x) (+ x 42)))
> (funcall #'foo 11))) => 53
>
> (let ((foo "I am foo"))
> (flet ((foo (x) (+ x 42)))
> (funcall foo 11))) => error, can't apply a string
>
> (let ((foo "I am foo"))
> (flet ((foo (x) (+ x 42)))
> (funcall 'foo 11))) => error, symbol foo has no function
> binding
> The first example works because writing #'foo (which is the same as
> writing (FUNCTION foo)) tells the compiler that you want to treat the
> name foo as a function, not a variable. There is a lexically visible
> function name bound by the FLET, so that is #'foo means. The *symbol*
> foo (our little struct) has no role in this interaction.
>
> I hope this helps.
>
Very much so, thank you. I'm a little confused with the examples given
though. I understand them, and understand now how they work. My confusion
lies in the fact that scope doesn't seem to be playing a role? By reading
the code, I assume "flet foo" to override "let foo" in scope. So whether
using #'foo or 'foo or foo, they would all point to "flet foo". However,
your example (which I test and confirm) says otherwise. Is there no
scoping in CL? or does it just work differently? are functions stored in
a separate "namespace" than other atoms?
I assume if I did:
(defun add-x (a x)
(let ((x 4))
(+ a x)))
(add-x 5 6) => 9
God I hope that is right. However, from what is stated above:
(defun add-x (a x)
(flet ((x () 4))
(+ a x)))
(add-x 5 6) => 11
This will take some getting used to... is there any particular reason for
the ANSI spec to be done this way? advantages?
Thanks again for the great explanation. That would have taken me quite a
while to figure out myself.
--
Best regards,
Jeff ··········@mfire.com
http://www.simforth.com
Jeff Massung <···@NOSPAM.mfire.com> writes:
> (defun add-x (a x)
> (flet ((x () 4))
> (+ a x)))
>
> (add-x 5 6) => 11
>
> This will take some getting used to... is there any particular reason for
> the ANSI spec to be done this way? advantages?
Yes. Because this is not the common case we worry about. FLET is not
uncommon in Common Lisp, but overall the use of local functions in CL
is intentionally a lot lower than in Scheme.
Consider that if you didn't know about ASSOC, you might write:
(defun car-color (car color-correspondence-list)
(dolist (pair correspondence-list)
(when (eq (car pair) car)
(return (cdr pair)))))
The theory in CL is that deciding to use a certain parameter name ought not
imply a decision that a function by that name should not be usable in this
environment.
In Scheme you have to make sure you never use a parameter name that names
a function you'd like to use, which we find frustrating. I often write code
like:
(defun check-package-name (package-name)
(block fail
(dolist (package (list-all-packages))
(when (or (equal (package-name package) package-name)
(find package-name (package-nicknames package) :test #'equal))
(return-from fail nil)))
t))
Here PACKAGE-NAME is u sed as an accessor and as a parameter name.
The thing is that using a name that suggests the type of an argument is
handy, but a lot of such names are already the name of constructors or
accessors.
In Scheme the common answer is to misspell the parameter. e.g.,
(define (check-package-name pkg-name) ...)
or (define (car-color kar color-correspondence-list) ...)
or even (define (car-color auto color-correspondence-list) ...)
A design decision was made in CL not to have to make such accomodations.
For further detailed information on this topic, see
http://www.nhplace.com/kent/Papers/Technical-Issues.html
Often, too, and this is more subtle, what you might do with closures in
Scheme is done in other ways in CL. For example, examine some functions
like SORT or FIND and consider how they would be cast into Scheme.
Rather than CL's
(sort foo #'< :key #'car)
Scheme might do
(sort foo (lambda (x y) (< (car x) (car y))))
The design choice of CL to use keywords means that a lot of things
you think of as functions, we don't, so we don't see intervening new
functions nearly as often as you might be used to. And this has some
consequential effects on our preferences for how certain kinds of
code is case-marked, too. This might be hard to see at first, but
it's one reason why you have to just get used to programming for a while
and then view the language as a whole--isolated features are hard to
examine fairly out of context.
I've often said and I will repeat here: There is no Good or Bad language
feature in the abstract; language design decisions are only good or
bad in the context of use. It is as if they are part of an ecology,
and the overall ecology either works or doesn't. Features are
interdependent and cannot stand in isolation, nor can they be judged
that way.
Hope this helps.
Kent M Pitman <······@world.std.com> wrote in
····················@shell01.TheWorld.com:
>
> Hope this helps.
Tremendously, thanks everyone. The functions being in a separate namespace
is something I haven't found in any Lisp book so far (perhaps I just missed
it). It completely explains the need for #' and if anyone here plans on
writing tutorials or more books, I highly suggest commenting on this
somewhere :) I wouldn't have even thought to look for it.
Thanks again!
--
Best regards,
Jeff ··········@mfire.com
http://www.simforth.com
In article <··············@corp.supernews.com>,
Jeff Massung <···@NOSPAM.mfire.com> wrote:
>Tremendously, thanks everyone. The functions being in a separate namespace
>is something I haven't found in any Lisp book so far (perhaps I just missed
>it). It completely explains the need for #' and if anyone here plans on
>writing tutorials or more books, I highly suggest commenting on this
>somewhere :) I wouldn't have even thought to look for it.
You mentioned in a recent post that you're working through
Lisp in Small Pieces. This book focuses on the Scheme
dialect of Lisp which, unlike Common Lisp, doesn't have
separate variable and function namespaces. So perhaps
this is why you haven't seen this distinction mentioned
yet.
sv0f <····@vanderbilt.edu> wrote in
·······························@news.vanderbilt.edu:
> In article <··············@corp.supernews.com>,
> Jeff Massung <···@NOSPAM.mfire.com> wrote:
>
>>Tremendously, thanks everyone. The functions being in a separate
>>namespace is something I haven't found in any Lisp book so far
>>(perhaps I just missed it). It completely explains the need for #' and
>>if anyone here plans on writing tutorials or more books, I highly
>>suggest commenting on this somewhere :) I wouldn't have even thought
>>to look for it.
>
> You mentioned in a recent post that you're working through
> Lisp in Small Pieces. This book focuses on the Scheme
> dialect of Lisp which, unlike Common Lisp, doesn't have
> separate variable and function namespaces. So perhaps
> this is why you haven't seen this distinction mentioned
> yet.
>
I'm also reading PG's ANSI Common Lisp at the same time. Perhaps I just
haven't found it yet, but so far it isn't in there either.
Thanks again for all the help, everyone!
--
Best regards,
Jeff ··········@mfire.com
http://www.simforth.com
sv0f <····@vanderbilt.edu> writes:
> You mentioned in a recent post that you're working through
> Lisp in Small Pieces. This book focuses on the Scheme
> dialect of Lisp which,
It _uses_ Scheme to implement several different lisps.
> unlike Common Lisp, doesn't have separate variable and function
> namespaces.
My copy of L.i.S.P. has dedicated chapter 2, "Lisp, 1, 2, ... \omega",
to precisely this theme.
--
chr
On Fri, Jun 13, 2003 at 06:38:08PM -0000, Jeff Massung wrote:
> Very much so, thank you. I'm a little confused with the examples given
> though. I understand them, and understand now how they work. My confusion
> lies in the fact that scope doesn't seem to be playing a role? By reading
> the code, I assume "flet foo" to override "let foo" in scope. So whether
> using #'foo or 'foo or foo, they would all point to "flet foo". However,
> your example (which I test and confirm) says otherwise. Is there no
> scoping in CL? or does it just work differently? are functions stored in
> a separate "namespace" than other atoms?
Functions are indeed in a separate namespace. I suppose Joe didn't
quite emphasize this enough, but, not only is the CAR of a form
considered to be a special op, macro, function, or lambda expression, but
in addition, if it is a function then it is looked up in the function
namespace, not the variable namespace.
FLET, LABELS, DEFUN all establish bindings in the function namespace.
> I assume if I did:
>
> (defun add-x (a x)
> (let ((x 4))
> (+ a x)))
>
> (add-x 5 6) => 9
Right, because LET establishes a variable binding.
> (defun add-x (a x)
> (flet ((x () 4))
> (+ a x)))
>
> (add-x 5 6) => 11
And FLET establishes a function binding. On the other hand, if you had
(+ a (x))
in there, you would be calling the function named X, and that would be
looked up in the function namespace.
(+ a x) means add the variable A to the variable X.
(x) means call the function named X with no arguments.
The canonical example is something like:
(let ((f 1))
(flet ((f (f)
(* 2 f)))
(f f)))
Function bindings are used in one of two ways:
* Named by the first symbol in a form
* Argument to the special operator FUNCTION (shorthand: #')
Note that function bindings are distinct from function values. Function
values can be treated as normal values and bound to normal variables.
(let ((x (lambda () 1)))
;; (x) would not work here
(funcall x))
But since X is in the variable namespace, this example will not work if
X is the first element of a form, because the compiler will assume you
mean the X in the function namespace. Therefore, you use FUNCALL.
> This will take some getting used to... is there any particular reason for
> the ANSI spec to be done this way? advantages?
It's nice not to have to play dodgy games with variable names in order
not to conflict with function names:
(defvar list (list 1 2 3)) ;-)
Helps with macros too, avoiding function name capture.
(let ((list ...))
(some-macro-that-uses-list-function ...))
;; no problems!
--
; 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."
Matthew Danish <·······@andrew.cmu.edu> writes:
> It's nice not to have to play dodgy games with variable names in order
> not to conflict with function names:
>
> (defvar list (list 1 2 3)) ;-)
No, that would proclaim LIST special, which triggers undefined
consequences according to item 10 of CLHS section 11.1.2.1.2.
(Such a proclamation could disturb code that tries to bind LIST
lexically.)
A lexical variable is OK, however.
Jeff Massung <···@NOSPAM.mfire.com> writes:
> Very much so, thank you. I'm a little confused with the examples given
> though. I understand them, and understand now how they work. My confusion
> lies in the fact that scope doesn't seem to be playing a role? By reading
> the code, I assume "flet foo" to override "let foo" in scope. So whether
> using #'foo or 'foo or foo, they would all point to "flet foo". However,
> your example (which I test and confirm) says otherwise. Is there no
> scoping in CL? or does it just work differently?
> are functions stored in a separate "namespace" than other atoms?
That's right. The FUNCTION special form is simply a namespace
qualifier.
The FLET binds in the function namespace, the LET binds in the
variable namespace.
> I assume if I did:
>
> (defun add-x (a x)
> (let ((x 4))
> (+ a x)))
>
> (add-x 5 6) => 9
>
> God I hope that is right. However, from what is stated above:
>
> (defun add-x (a x)
> (flet ((x () 4))
> (+ a x)))
>
> (add-x 5 6) => 11
You got it.
>
> This will take some getting used to... is there any particular reason for
> the ANSI spec to be done this way? advantages?
Don't ask. (Or look it up on google. This question comes up about
twice a year and spawns a ton of debate. The end result is: it's the
way it is. Some people find it easier, some find it harder.)
In article <··············@corp.supernews.com>,
Jeff Massung <···@NOSPAM.mfire.com> wrote:
>Very much so, thank you. I'm a little confused with the examples given
>though. I understand them, and understand now how they work. My confusion
>lies in the fact that scope doesn't seem to be playing a role? By reading
>the code, I assume "flet foo" to override "let foo" in scope. So whether
>using #'foo or 'foo or foo, they would all point to "flet foo". However,
>your example (which I test and confirm) says otherwise. Is there no
>scoping in CL? or does it just work differently? are functions stored in
>a separate "namespace" than other atoms?
Yes, Common Lisp has a separate namespace for functions and variables.
FLET binds the name in the function namespace, but this has no effect on
its use as a variable, and vice versa.
>I assume if I did:
>
>(defun add-x (a x)
> (let ((x 4))
> (+ a x)))
>
>(add-x 5 6) => 9
>
>God I hope that is right. However, from what is stated above:
>
>(defun add-x (a x)
> (flet ((x () 4))
> (+ a x)))
>
>(add-x 5 6) => 11
Correct. And for completeness, here's:
(defun add-x (a x)
(flet ((x () 4))
(+ a (x))))
(add-x 5 6) => 9
--
Barry Margolin, ··············@level3.com
Level(3), 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.
Jeff Massung <···@NOSPAM.mfire.com> wrote in message news:<··············@corp.supernews.com>...
> Okay, I'm having a little difficulty understand when to use ' or #' and am
> hoping someone can lend a simple example.
> I understand that QUOTE returns the symbol (or whatever is quoted) and
> FUNCTION returns the actual function.
That's correct.
The difference manifests itself in two circumstances. Firstly, if you
have a symbol, then if the function is dynamically redefined, the
symbol's global function binding points to the new version. So using
QUOTE leaves your program more flexible against redefinition. When you
redefine a function FOO, the values of any previously evaluated
(FUNCTION FOO) expressions do not change; they continue to be
references to the old function-object.
The other circumstance in which the difference matters is when you
have lexically scoped functions introduced by FLET or LABELS. These
cannot be indirected upon using QUOTE; they are lexical bindings, not
symbol-function slots. So this won't work:
(labels ((my-function () ...))
(funcall 'my-function ...))
but it will work with #' because the (FUNCTION ...) operator works
specially with lexically scoped functions.
Common Lisp is designed so that it's easy and natural to write code
that works both ways. This is so because the applicative operators
such as FUNCALL, APPLY, MAPCAR and so forth, are all generic: they
take a symbol or a function object.
However, I can't seem to get either
> to work on a test sample that I'm trying in order to clear up the
> difference in my mind.
>
> I'm trying this:
>
> ((if t + -) 1 2) ; doesn't work
> ((if t '+ '-) 1 2) ; doesn't work
> ((if t #'+ #'-) 1 2) ; doesn't work
Because when you evaluate a list as a function, operator or macro
call, the first position of the list must be the name of a function.
The name of a function is a symbol, or (setf <symbol>). A lambda
expression may be used in place of the name of a function. No
evaluation is applied to the first position of a list to reduce it to
one of these objects; the source code must literally be a function
name or a lambda expression, not some expression which can compute one
of these.
If you want to indirect on a symbol's function binding to call the
function, or if you want to call a function object directly, you must
use one of the applicative operators: FUNCALL, APPLY, MAPCAR, etc.
> Why do none of these work? If #' is the correct version (and I'm just doing
> something wrong) then what is the difference between #'+ and just +?
One is the expression (FUNCTION +), the other is the expression + .
If you treat these as data, one is a list, the other is a symbol. If
you treat them as expressions to be evaluated, one produces a function
object, the other evaluates the variable binding of the + symbol.
In article <··············@corp.supernews.com>,
Jeff Massung <···@NOSPAM.mfire.com> wrote:
>Okay, I'm having a little difficulty understand when to use ' or #' and am
>hoping someone can lend a simple example.
>
>I understand that QUOTE returns the symbol (or whatever is quoted) and
>FUNCTION returns the actual function. However, I can't seem to get either
>to work on a test sample that I'm trying in order to clear up the
>difference in my mind.
>
>I'm trying this:
>
>((if t + -) 1 2) ; doesn't work
>((if t '+ '-) 1 2) ; doesn't work
>((if t #'+ #'-) 1 2) ; doesn't work
>
>Why do none of these work? If #' is the correct version (and I'm just doing
>something wrong) then what is the difference between #'+ and just +?
Your problem isn't with the quoting, it's with the function-calling syntax.
In Common Lisp, the car of an expression is not evaluated normally, it's
required to be either an operator name or a lambda expression. If you want
to call a function that's computed you have to use FUNCALL:
(funcall (if t #'+ #'-) 1 2)
This will also work, but it's not usually considered good style:
(funcall (if t '+ '-) 1 2)
Your first expression would be appropriate for Scheme, but not CL.
--
Barry Margolin, ··············@level3.com
Level(3), 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.