Hello,
Here is a simple function definition:
(defun plus-one (x) (+ x 1))
(plus-one 1) -> 2
Here is a function definition that makes use of another function:
(defun plus-two (x) (plus-one (plus-one x)))
(plus-two 2) -> 4
Now I would like to be able to write a function which can take arbitrary
functions in the parameter list and apply them to elements in the function
body. For this purpose I tried to write the conceptually simple function
apply-fun which would take a function f and a variable x to produce the
result of applying f to x. Unfortunately something went wrong:
(defun apply-fun (f x) (f x))
(apply-fun plus-two 4) -> *** - EVAL: variable PLUS-TWO has no value
-> Error: The variable PLUS-TWO is unbound.
-> Fast links are on: do (si::use-fast-links nil)
-> for debugging
-> Error signalled by EVAL.
-> Broken at APPLY-FUN. Type :H for Help.
I also tried the following, but I got the same error.
(defun apply-fun (f x) (apply f (cons x NIL)))
Is there a way I can tell lisp that f is a function and not a variable?
Once I get this to work I should be able to write more complicated functions
which take functions in the parameter list. Any ideas of what might have
gone wrong in the definition of apply-fun ?
Thanks,
Neil
On Sun, 14 Oct 2001, Neil Zanella wrote:
> (defun plus-one (x) (+ x 1))
> (defun plus-two (x) (plus-one (plus-one x)))
> (defun apply-fun (f x) (f x))
> (defun apply-funct (f x) (apply f (cons x NIL)))
Just to be a little bit clearer I was only asking for an explanation
(apply-funct 'plus-two 2)
works but the similar looking function application
(apply-fun 'plus-two 2)
does not work, resulting in the message:
*** - EVAL: the function F is undefined
Do I really have to use apply here or is there another way
so that I don't have to cons x into NIL?
Thanks,
Neil
From: Frode Vatvedt Fjeld
Subject: Re: CL: question made clearer: passing a function to a function
Date:
Message-ID: <2hadytagwf.fsf@dslab7.cs.uit.no>
Common Lisp has two namespaces: The "regular" one, and one for
functions (and other operators). The first position in a list form
(meaning a list to be evaluated, like "(plus-one 3)") automatically
uses the operator namespace, whereas the other positions uses the
regular namespace.
Neil Zanella <········@garfield.cs.mun.ca> writes:
> Do I really have to use apply here or is there another way so that I
> don't have to cons x into NIL?
Your problem is that you have a function located in the regular
namespace, and you want to call it. The function FUNCALL exists for
this purpose. It accepts a function name (or an actual function
object), looks it up in the operator namespace, and applies it to the
rest of the arguments passed to it. (funcall 'plus-one 3) => 4.
--
Frode Vatvedt Fjeld
On Mon, 15 Oct 2001, Frode Vatvedt Fjeld wrote:
> Common Lisp has two namespaces: The "regular" one, and one for
> functions (and other operators). The first position in a list form
> (meaning a list to be evaluated, like "(plus-one 3)") automatically
> uses the operator namespace, whereas the other positions uses the
> regular namespace.
>
> Your problem is that you have a function located in the regular
> namespace, and you want to call it. The function FUNCALL exists for
> this purpose. It accepts a function name (or an actual function
> object), looks it up in the operator namespace, and applies it to the
> rest of the arguments passed to it. (funcall 'plus-one 3) => 4.
I guess funcall is similar to apply except it does not require the
arguments to be contained in a list. Correct?
Thank you for introducing me to the funcall lisp operator: it seems
to do exactly what I was looking for except that just like with apply
the GCL implementation does not seem to work with lambda functions,
unlike the clisp implementation:
CLISP> (funcall (lambda (x) (+ x 1)) 1)
-> 2
(hurray!)
GCL> (funcall (lambda (x) (+ x 1)) 1)
-> Error: The function LAMBDA is undefined.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at FUNCALL. Type :H for Help.
(boooo!)
Now how do I convince GCL to do the right thing just like clisp does.
Is there some syntactical problem? As far as I know lambda definitions
are part of the Common Lisp hyperspec. Is GCL not fully compiant with
the spec or is the spec simply blurry on what should happen in the
above case?
Thanks,
Neil
"Neil Zanella" <········@garfield.cs.mun.ca> wrote in message
·············································@garfield.cs.mun.ca...
>
> CLISP> (funcall (lambda (x) (+ x 1)) 1)
> -> 2
>
> (hurray!)
>
> GCL> (funcall (lambda (x) (+ x 1)) 1)
> -> Error: The function LAMBDA is undefined.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by EVAL.
> Broken at FUNCALL. Type :H for Help.
>
> (boooo!)
>
> Now how do I convince GCL to do the right thing just like clisp does.
> Is there some syntactical problem? As far as I know lambda definitions
perhaps (funcall #'(lambda (x) (+ x 1)) 1) would do the trick.
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
Neil Zanella <········@garfield.cs.mun.ca> writes:
>
> Now how do I convince GCL to do the right thing just like clisp does.
> Is there some syntactical problem? As far as I know lambda definitions
> are part of the Common Lisp hyperspec. Is GCL not fully compiant with
> the spec or is the spec simply blurry on what should happen in the
> above case?
>
GCL is not compliant.
You can probably do this though (this code is *also* not compliant, but
I think it will work in GCL):
(defmacro lambda (args &body body)
`#'(lambda ,args ,@body))
--tim
From: Janis Dzerins
Subject: Re: CL: question made clearer: passing a function to a function
Date:
Message-ID: <87n12tp4ku.fsf@asaka.latnet.lv>
Neil Zanella <········@garfield.cs.mun.ca> writes:
> Now how do I convince GCL to do the right thing just like clisp
> does.
Is there any reason you want to use GCL over clisp if it already does
the right thing?
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
From: Kent M Pitman
Subject: Re: CL: question made clearer: passing a function to a function
Date:
Message-ID: <sfwadytsjwl.fsf@world.std.com>
Frode Vatvedt Fjeld <······@acm.org> writes:
>
> Common Lisp has two namespaces: The "regular" one, and one for
> functions (and other operators). The first position in a list form
> (meaning a list to be evaluated, like "(plus-one 3)") automatically
> uses the operator namespace, whereas the other positions uses the
> regular namespace.
>
> Neil Zanella <········@garfield.cs.mun.ca> writes:
>
> > Do I really have to use apply here or is there another way so that I
> > don't have to cons x into NIL?
>
> Your problem is that you have a function located in the regular
> namespace, and you want to call it. The function FUNCALL exists for
> this purpose. It accepts a function name (or an actual function
> object), looks it up in the operator namespace, and applies it to the
> rest of the arguments passed to it. (funcall 'plus-one 3) => 4.
Don't use 'plus-one if you can help it. Prefer #'plus-one.
The two are slightly different. 'plus-one is a symbol, and symbols are
coerced by getting the globally defined function definition. #'plus-one
is a special operator that gets the innermost lexically bound function
named plus-one, which is almost usually what you want. e.g.,
(flet ((add1 (x) (+ x 1)))
(foo #'add1))
will work but
(flet ((add1 (x) (+ x 1)))
(foo 'add1))
will lose because it will look for a globally defined ADD1 instead of finding
the lexically bound ADD1.
Kent M Pitman <······@world.std.com> writes:
> Don't use 'plus-one if you can help it. Prefer #'plus-one.
I was once trying to install CLG (GTK+ for CL) and debugging a
defsystem-related problem. MK:DEFSYSTEM has a global hash table
that contains structures, and one of the structures had
#'C-COMPILE-FILE in a slot. I was hacking that function and
every time I evaluated the DEFUN, I had to explicitly update the
structure to refer to the new definition. In the end, I put the
symbol there instead and things started going much smoother.
This made me feel that data structures should refer to functions
via symbols if possible.
From: Kent M Pitman
Subject: Re: CL: question made clearer: passing a function to a function
Date:
Message-ID: <sfwy9mbvn7e.fsf@world.std.com>
Kalle Olavi Niemitalo <···@iki.fi> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Don't use 'plus-one if you can help it. Prefer #'plus-one.
>
> I was once trying to install CLG (GTK+ for CL) and debugging a
> defsystem-related problem. MK:DEFSYSTEM has a global hash table
> that contains structures, and one of the structures had
> #'C-COMPILE-FILE in a slot. I was hacking that function and
> every time I evaluated the DEFUN, I had to explicitly update the
> structure to refer to the new definition. In the end, I put the
> symbol there instead and things started going much smoother.
>
> This made me feel that data structures should refer to functions
> via symbols if possible.
I know people that do this. There's often no guarantee that the
program you're passing it to won't do (setq fn (coerce fn 'function))
and leave you in the same state as before, though. More reliable and
having the same effect is generally
#'(lambda (file) (c-compile-file file))
if that's what you really want. Or
#'(lambda (file)
(declare (notinline c-compile-file))
(c-compile-file file))
if you are totally paranoid.
I'm not saying there aren't places where it's useful to pass a symbol
instead of a function. I'm saying that all the uses that I can think
of are kludges to be used by sophisticated programmers to do something
clever. And the conventional wisdom is that novices are almost always
shooting themselves in the foot when they try to be clever.
Kent M Pitman <······@world.std.com> writes:
> #'(lambda (file) (c-compile-file file))
Thanks. I learned something again. I had been assuming that the
version for a variable number of arguments,
#'(lambda (&rest args)
(apply #'c-compile-file args))
would grab the function definition of C-COMPILE-FILE into the
compiled code, as a consequence of using FUNCTION. Of course it
doesn't, because C-COMPILE-FILE need not even be defined when the
anonymous function is compiled; the inner FUNCTION form is not
evaluated at that time. It doesn't cache the definition the
first time it *is* evaluated, either.
This would remember the previous definition of C-COMPILE-FILE:
(let ((saved-c-compile-file #'c-compile-file))
#'(lambda (&rest args)
(apply saved-c-compile-file args)))
This would save the definition the first time it is called:
(let ((saved-c-compile-file nil))
#'(lambda (&rest args)
(unless saved-c-compile-file
(setq saved-c-compile-file #'c-compile-file))
(apply saved-c-compile-file args)))
Both of these expressions are more complex than the original,
and rightly so.
From: Brian P Templeton
Subject: Re: CL: question made clearer: passing a function to a function
Date:
Message-ID: <87wv1w8qnh.fsf@tunes.org>
Try this:
(defun plus-one (x) (+ x 1))
(defun plus-two (x) (plus-one (plus-one x)))
(defun apply-fun (f x) (funcall f x))
(apply-fun #'plus-two 2)
CL is an n-valued language, meaning that the result of evaluating the
symbol x can have a different result depending on what context it is
evaluated in. For example, (setq x 5) stores 5 into the value cell of
the symbol x, and (defun x () nil) stores the function (lambda () nil)
into the function cell of the symbol x. If x is in the car of a list
that is being evaluated, then it will evaluate to the contents of the
function cell of the symbol x; otherwise, it will evaulate to the
contents of the value cell of the symbol x. The FUNCTION function (and
#' is a macro character which invokes that function) returns *as a
value* the contents of the function cell of the following
S-expression. That means that, when apply-fun is called, the symbol f
within the function has (lambda (x) (plus-one (plus-one x))) in the
*value cell* of the symbol f. That is why you must use funcall instead
of just (f x).
I hope I did not explain anything incorrectly there, and please
followup to this if it isn't clear (I doubt it is). It is a very
confusing subject, and I was very confused until a few weeks ago,
also. The separation of function and value namespaces is confusing
enough that I think Scheme's monovaluedness is one of its only
advantages over Common Lisp.
hth,
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
From: Kent M Pitman
Subject: Re: CL: question made clearer: passing a function to a function
Date:
Message-ID: <sfwg08ko5u7.fsf@world.std.com>
Brian P Templeton <···@tunes.org> writes:
> The separation of function and value namespaces is confusing
> enough that I think Scheme's monovaluedness is one of its only
> advantages over Common Lisp.
Some people are determined to be bugged about it, but it's a very
common language choice. Lots of languages have this separation. What
many languages that separate functions and values DON'T have are notations
that allow you to shuttle back and forth between the namespaces. It might
confuse people less for the language to merely omit the ability to do this,
but that would seem darned strange.
From: Juliusz Chroboczek
Subject: Re: CL: question made clearer: passing a function to a function
Date:
Message-ID: <87pu7nw8rt.fsf@pps.jussieu.fr>
BT> It is a very confusing subject, and I was very confused until a
BT> few weeks ago, also. The separation of function and value
BT> namespaces is confusing enough that I think Scheme's
BT> monovaluedness is one of its only advantages over Common Lisp.
I used to think so too, until I realised what a great feature it is.
In a large language such as CL, or when using a large system, it is
quite easy to inadvertently reuse the name of an already defined
function. Thanks to Lisp having multiple namespaces, care is only
needed when defining a function or a special variable.
Thus, one can safely say
(defun foo (list)
(mapcar #'bar list))
or
(go loop)
or
(return values).
(Note that while technically CL uses the same namespace for lexical
and special variables, the common ``*foo*'' convention has the effect
of partitioning it.)
I don't deny that it is difficult to explain to newbies.
Juliusz
"Neil Zanella" <········@garfield.cs.mun.ca> wrote in message
············································@garfield.cs.mun.ca...
>
> Hello,
>
> Here is a simple function definition:
>
> (defun plus-one (x) (+ x 1))
> (plus-one 1) -> 2
>
> Here is a function definition that makes use of another function:
>
> (defun plus-two (x) (plus-one (plus-one x)))
> (plus-two 2) -> 4
>
> Now I would like to be able to write a function which can take arbitrary
> functions in the parameter list and apply them to elements in the function
> body. For this purpose I tried to write the conceptually simple function
> apply-fun which would take a function f and a variable x to produce the
> result of applying f to x. Unfortunately something went wrong:
>
> (defun apply-fun (f x) (f x))
what you want here is:
(defun apply-fun (f x) (funcall f x))
> (apply-fun plus-two 4) -> *** - EVAL: variable PLUS-TWO has no value
which should be called like:
(apply-fun #'plus-two 4)
> -> Error: The variable PLUS-TWO is unbound.
>
> (defun apply-fun (f x) (apply f (cons x NIL)))
>
> Is there a way I can tell lisp that f is a function and not a variable?
>
Actually f is a symbol. It has both a "normal" value and a function value. To
get the function value use the #' as above which is shorthand for (function f)
This must then be invoke with funcall, it is not enough to just put it first in
the sexp.
> Once I get this to work I should be able to write more complicated functions
The sky's the limit! ;-)
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
From: Kent M Pitman
Subject: Re: Common Lisp: passing a function to a function and applying it
Date:
Message-ID: <sfwbsj9sk0r.fsf@world.std.com>
Neil Zanella <········@garfield.cs.mun.ca> writes:
> (defun apply-fun (f x) (f x))
(defun apply-fun (f x) (funcall f x))
Lisp, unlike Scheme, separates the "variable" from the "function" namespace.
Functions can live in variables, but they are still in the variable namespace.
Normal evaluation happens in the variable namespace. FUNCALL is used to
call a function that is produced under normal (variable) evaluation.
The car of a form is ONLY permitted to be something you defined as a function
(usually by DEFUN, though also by SETF of SYMBOL-FUNCTION), or else a LAMBDA
expression. Arbitrary forms for evaluate are not permitted directly in the
car of a form. When you want that, just put FUNCALL in the car of the form
and the form you wanted in the car into the cadr.
> (apply-fun plus-two 4) -> *** - EVAL: variable PLUS-TWO has no value
This is the reverse problem. A function defined in the function namespace
is not a variable. To move something from the function namespace to the
variable namespace, use the special operator FUNCTION.
(apply-fun (function plus-two) 4)
Though usually we use the shorthand notation
(apply-fun #'plus-two 4)
> I also tried the following, but I got the same error.
>
> (defun apply-fun (f x) (apply f (cons x NIL)))
You could have said (list x) instead of (cons x nil) here.
(apply f (list x)) is the same as (funcall f x).
So that would have worked if you'd gotten that far. But you still
have to say
(apply-fun #'plus-two 4)
to get far enough to see that this change of yours solved your first
problem above. Use FUNCALL if you can, rather than APPLY as you have
done here, so you don't have to cons the spurious (list x).
> Is there a way I can tell lisp that f is a function and not a variable?
#'f
> Once I get this to work I should be able to write more complicated functions
> which take functions in the parameter list. Any ideas of what might have
> gone wrong in the definition of apply-fun ?
You were either taught by someone who knows Scheme rather than Lisp
or else you were just guessing at the semantics. It helps to read a
document that tells you how things work.
If you get some time, read the description of the Lisp evaluator in
CLHS.
http://www.xanalys.com/software_tools/reference/HyperSpec/FrontMatter/
On Mon, 15 Oct 2001, Kent M Pitman wrote:
> (defun apply-fun (f x) (funcall f x))
>
> Lisp, unlike Scheme, separates the "variable" from the "function" namespace.
> Functions can live in variables, but they are still in the variable namespace.
> Normal evaluation happens in the variable namespace. FUNCALL is used to
> call a function that is produced under normal (variable) evaluation.
Thanks for your explanation. The funcall construct is really useful when
you want to apply a function passed to a procedure as a variable in the
argument list to a single element within that procedure. Alternatively
one can use mapcar to apply such a function to a list of arguments to
obtain the list of componentwise evaluated arguments.
> The car of a form is ONLY permitted to be something you defined as a function
> (usually by DEFUN, though also by SETF of SYMBOL-FUNCTION), or else a LAMBDA
> expression. Arbitrary forms for evaluate are not permitted directly in the
> car of a form. When you want that, just put FUNCALL in the car of the form
> and the form you wanted in the car into the cadr.
If this were correct then why is it that
the following does not work with GCL:
GCL> (funcall (lambda (x) (+ x 1)) '9)
Error: The function LAMBDA is undefined.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at FUNCALL. Type :H for Help.
??? Is this a bug in GCL ???
CLISP> (funcall (lambda (x) (+ x 1)) '9)
10
It seems to me as though GCL is having some problems interpreting the
lambda notation but it does work when funcall is not used as in the
following example:
GCL> ((lambda (x) (+ x 1)) '9)
10
> http://www.xanalys.com/software_tools/reference/HyperSpec/FrontMatter/
Thanks for pointing me to the Common Lisp HyperSpec. This seems to be the
standard reference for ANSI Common Lisp.
Thanks,
Neil
From: Janis Dzerins
Subject: Re: Common Lisp: passing a function to a function and applying it
Date:
Message-ID: <87vghhp6zp.fsf@asaka.latnet.lv>
Neil Zanella <········@garfield.cs.mun.ca> writes:
> GCL> (funcall (lambda (x) (+ x 1)) '9)
> Error: The function LAMBDA is undefined.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by EVAL.
> Broken at FUNCALL. Type :H for Help.
>
> ??? Is this a bug in GCL ???
Yes. GCL is not a little out of date as far as conformace to the
standard goes.
The expression works in CLISP because in Common Lisp there are both
special form "lambda" and macro "lamda", which expands to (function
(lambda ...)), which is the same as #'(lambda ...).
--
Janis Dzerins
Eat shit -- billions of flies can't be wrong.
In article <·······································@garfield.cs.mun.ca>,
Neil Zanella wrote:
>Is there a way I can tell lisp that f is a function and not a variable?
By passing a function object in the call, created using the (function ...)
special operator, and by calling that function object using funcall
or apply. The shorthand #'<form> is often used instead of
(function <form>) in idiomatic Lisp.
(defun apply-function (f x) (funcall f x))
(function-takes-function #'car '(42 43))
===> 42
Of course, it should be apparent that, apply-function is a completely
useless wrapper for funcall, since the caller can just use it directly:
(funcall #'car '(42 43))
By the way, you must use funcall or apply. You cannot just write (f x),
because Lisp has special evaluation rules for the leftmost position of
a form, and because symbols have separate function and value bindings.
When you evaluate (f x), then the symbol f must have a function binding.
A binding to a function-object, like #'car is not a function binding,
but a value binding.