Hi,
I understand the need to use funcall in CL; because it has different
namespaces for functions and variables. But I don't quite understand
the need of it for closures, like:
(defun foo ()
(lambda (x) (* x x)))
(funcall (foo) 10) => 100
((foo) 10) => error
since (foo) returns a function object, why funcall is needed?
Of course we can use lambda directly, with or without funcall:
((lambda (x) (* x x)) 10) => 100
(funcall (lambda (x) (* x x)) 10) => 100
but that's because lambda here refers to the _symbol_ lambda [1]
Again, I understand that funcall says "apply the function object
returned by (foo) to the argument 10", but I don't understand why it's
needed in this context where (foo) is clearly not a variable.
Pedro Kröger
[1] http://www.lisp.org/HyperSpec/Body/sym_lambda.html
Pedro Kröger wrote:
> Hi,
>
> I understand the need to use funcall in CL; because it has different
> namespaces for functions and variables. But I don't quite understand
> the need of it for closures, like:
>
> (defun foo ()
> (lambda (x) (* x x)))
>
> (funcall (foo) 10) => 100
> ((foo) 10) => error
>
> since (foo) returns a function object, why funcall is needed?
Because (foo) returns a function object and the evaluation rules don't
allow a function object there.
See
http://www.lispworks.com/documentation/HyperSpec/Body/03_abab.htm
Glenn
·············@specastro.com escreveu:
> Because (foo) returns a function object and the evaluation rules don't
> allow a function object there.
thanks for your answer. but that's sort of my point. is there any
reason for not allowing function objects in this position in the
evaluation rules?
Pedro
Pedro Kröger ha escrito:
> ·············@specastro.com escreveu:
>
> > Because (foo) returns a function object and the evaluation rules don't
> > allow a function object there.
>
> thanks for your answer. but that's sort of my point. is there any
> reason for not allowing function objects in this position in the
> evaluation rules?
I think that because a function object have the same rules as a
variable, not as a function:
(defun foo ()
(lambda (x) (* x x)))
CL-USER> (setq jj (foo))
#<FUNCTION (LAMBDA (X)) {11A14D8D}>
CL-USER> (jj)
=> error
You cannot call directly the returning value of foo for tha same
reasons you cannot call (jj). They are not symbol functions and their
names cannot be resolved. This is because Lisp have different
namespaces for variables and functions. For using the syntax (foo) or
(jj), foo or jj must reside first in the function namespace. In this
case, it doesn't reside there, just because the returning value of foo
is an anonymous function.
I clarify myself...
> case, it doesn't reside there, just because the returning value of foo
> is an anonymous function.
There may be the case which is not anonymous and cannot be called if
using the incorrect name. For example, if the function is stored as
foo2 but you are trying to call it from a variable named jj2 which
contains its function object.
"Pedro Kr�ger" <············@gmail.com> writes:
> ·············@specastro.com escreveu:
>
>> Because (foo) returns a function object and the evaluation rules don't
>> allow a function object there.
>
> thanks for your answer. but that's sort of my point. is there any
> reason for not allowing function objects in this position in the
> evaluation rules?
The main raison is because Common Lisp is a lisp-2.
The first item in a form is not evaluated. It's directly compiled-in.
In: (sin 42)
SIN is resolved at compilation time, not at run time.
In: ((lambda (x) (* x 2)) 42)
the (lambda (x) (* x 2)) is compiled and resolved at compilation
time, not at run time.
For (let ((f (lambda (x) (* x 2)))) ; not your question
(f 42))
but also for:
(flet ((foo () (lambda (x) (* x 2)))) ; your question
((foo) 42))
the first item in the form would have to be resolved at run-time, like
in a lisp-1. This is not the choice made by Common Lisp.
Granted, the forms like ((foo) 42) could be distinguished
syntactically, so we could expand them to (funcall (foo) 42).
If you need it you can use a lisp-1 macro.
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/82994055009163e9/ba0b0ef287aa2fee?lnk=st&q=%22lisp-1%22+defmacro+group%3Acomp.lang.lisp&rnum=2&hl=en#ba0b0ef287aa2fee
it also work on (let ((f (lambda (x) (* x 2)))) ; not your question
(f 42))
--
__Pascal Bourguignon__ http://www.informatimago.com/
IMPORTANT NOTICE TO PURCHASERS: The entire physical universe,
including this product, may one day collapse back into an
infinitesimally small space. Should another universe subsequently
re-emerge, the existence of this product in that universe cannot be
guaranteed.
Pascal Bourguignon escreveu:
> The first item in a form is not evaluated. It's directly compiled-in.
[snip]
> SIN is resolved at compilation time, not at run time.
[snip]
> the (lambda (x) (* x 2)) is compiled and resolved at compilation
> time, not at run time.
Hum, I'm starting to understand. Like other things in CL it has to do
with things that are done in (compile|macro expand|run)* time. I don't
have a solid picture in my mind of each 'fase' yet and the consequences
of resolving some things in one 'time' instead of another.
> the first item in the form would have to be resolved at run-time, like
> in a lisp-1. This is not the choice made by Common Lisp.
I suppose I understand the main differences between lisp-1 and lisp-2,
but I'm not sure I understand this entirely. I mean, I don't fully
understand the relationship of resolving things in run-time or
compile-time with the choice of lisp-1 and lisp-2. could you, please,
point me to some documentations/books/articles/etc?
Pedro Kröger
"Pedro Kr�ger" <············@gmail.com> writes:
> Pascal Bourguignon escreveu:
>
>> The first item in a form is not evaluated. It's directly compiled-in.
> [snip]
>> SIN is resolved at compilation time, not at run time.
> [snip]
>> the (lambda (x) (* x 2)) is compiled and resolved at compilation
>> time, not at run time.
>
> Hum, I'm starting to understand. Like other things in CL it has to do
> with things that are done in (compile|macro expand|run)* time. I don't
> have a solid picture in my mind of each 'fase' yet and the consequences
> of resolving some things in one 'time' instead of another.
>
>> the first item in the form would have to be resolved at run-time, like
>> in a lisp-1. This is not the choice made by Common Lisp.
>
> I suppose I understand the main differences between lisp-1 and lisp-2,
> but I'm not sure I understand this entirely. I mean, I don't fully
> understand the relationship of resolving things in run-time or
> compile-time with the choice of lisp-1 and lisp-2. could you, please,
> point me to some documentations/books/articles/etc?
Well, the main difference comes about when you consider the
restrictions on symbols exported from COMMON-LISP.
http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm
These restrictions are designed to allow the implementations to
determine at compilation time the standard function to use, and
therefore to generate more efficient code for these standard functions
than the normal dispatch that needs to be done at run time for dynamic
functions.
Consider:
(defun f (x) (g x))
(defun h (x) (cl:car x)) ; usually written as (car x), I just explicitely
; show here that we're not considering a shadowed
; car symbol different from cl:car.
Since the definition of g can change at run time:
(defun g (x) (* 3 x))
(f 1)
(defun g (x) (+ 1 x))
(f 1)
the code generated for the function f must go thru an indirection.
The code generated in f is approximately equivalent to:
(funcall (symbol-function 'g) x)
On the other hand, thanks to the restrictions on the symbols in CL,
the code generated in h can be an efficient in-lined machine code
instruction.
[8]> (disassemble (compile (defun f (x) (g x))))
WARNING in F :
Function G is not defined
Disassembly of function F
(CONST 0) = G
1 required argument
0 optional arguments
No rest parameter
No keyword parameters
3 byte-code instructions:
0 (LOAD&PUSH 1)
1 (CALL1 0) ; reference to the constant symbol G
3 (SKIP&RET 2)
NIL
[9]> (disassemble (compile (defun h (x) (cl:car x))))
Disassembly of function H
1 required argument
0 optional arguments
No rest parameter
No keyword parameters
3 byte-code instructions:
0 (LOAD 1)
1 (CAR)
2 (SKIP&RET 2)
NIL
[10]>
In a lisp-1 like scheme, determining at compilation time that the
function is one of the standard function that could be optimized this
way is much more complicated.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live.
From: Rahul Jain
Subject: Re: why funcall is needed in things like ((foo) 10)
Date:
Message-ID: <873ba2ms5l.fsf@nyct.net>
"Pedro Kr�ger" <············@gmail.com> writes:
> I suppose I understand the main differences between lisp-1 and lisp-2,
> but I'm not sure I understand this entirely. I mean, I don't fully
> understand the relationship of resolving things in run-time or
> compile-time with the choice of lisp-1 and lisp-2. could you, please,
> point me to some documentations/books/articles/etc?
It basically means that there are two different syntactic contexts. The
first position in an sexpr to be evaluated is the "predicate" position.
It describes what action is to be taken (a "verb"). The rest of the
positions are any "subjects" or "objects" (the "nouns") to be
manipulated by that "predicate". Just like the word "record" has
different meaning when used as a verb vs. a noun, a lisp symbol or
expression can have different meanings when used as an operator vs. a
variable.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
+ Rahul Jain <·····@nyct.net>:
| Just like the word "record" has different meaning when used as a
| verb vs. a noun, a lisp symbol or expression can have different
| meanings when used as an operator vs. a variable.
A symbol yes, but an expression? Variables have SYMBOL-VALUE and
SYMBOL-FUNCTION, but an expression like (foo bar) doesn't have that
distinction, so I don't see a /technical/ reason why
((foo bar) this that)
couldn't be syntactic sugar for
(funcall (foo bar) this that)
But perhaps nobody felt a need for it, and maybe they thought the
funcall version is clearer anyhow. Personally, I have no problem with
having to write the occasional FUNCALL, and it does point out very
clearly to the reader that something special is going on. (If I ever
see a FUNCALLs of the above sort in the code, I would begin to suspect
that the writer was unfamiliar with generic functions.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Harald Hanche-Olsen escreveu:
> (If I ever
> see a FUNCALLs of the above sort in the code, I would begin to suspect
> that the writer was unfamiliar with generic functions.)
you sort of nailed it. :-)
I was using examples like these to show how closures can be used to
implement objects. I'll show generic funcions after that.
Of course if one find something like this ugly:
(funcall (funcall account2 'deposit) 100)
he can abstract it in some way, like:
(defun send (account operation amount)
(funcall (funcall account operation) amount))
(send account2 'deposit 100)
Pedro Kroger
From: Rahul Jain
Subject: Re: why funcall is needed in things like ((foo) 10)
Date:
Message-ID: <8764eyla3v.fsf@nyct.net>
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Rahul Jain <·····@nyct.net>:
>
> | Just like the word "record" has different meaning when used as a
> | verb vs. a noun, a lisp symbol or expression can have different
> | meanings when used as an operator vs. a variable.
>
> A symbol yes, but an expression? Variables have SYMBOL-VALUE and
> SYMBOL-FUNCTION, but an expression like (foo bar) doesn't have that
> distinction, so I don't see a /technical/ reason why
>
> ((foo bar) this that)
>
> couldn't be syntactic sugar for
>
> (funcall (foo bar) this that)
>
> But perhaps nobody felt a need for it, and maybe they thought the
> funcall version is clearer anyhow.
To me, it's clearer because the first position is a specific syntactic
context. Having funny rules about when those contexts are the same
causes confusion, as the special case for lambda expressions does, and
did for the OP. Although that case can sort of be explained away... sort
of...
Also, theoretically (foo bar) as an operator name could
have specific meaning, just as (setf bar) does. The mechanism of how to
define that meaning isn't CL.
Note that (setf bar) as a function name has a very different meaning
from (setf bar) as code to be evaluated.
> Personally, I have no problem with
> having to write the occasional FUNCALL, and it does point out very
> clearly to the reader that something special is going on. (If I ever
> see a FUNCALLs of the above sort in the code, I would begin to suspect
> that the writer was unfamiliar with generic functions.)
It would only indicate that if the code was of the form
(funcall (foo this that) this that).
If you lookup (or even compute!) a function based on different criteria
than the parameters to it, then a g-f won't buy you much.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
+ Rahul Jain <·····@nyct.net>:
| Harald Hanche-Olsen <······@math.ntnu.no> writes:
|
|> (If I ever see a FUNCALLs of the above sort in the code, I would
|> begin to suspect that the writer was unfamiliar with generic
|> functions.)
|
| It would only indicate that if the code was of the form
| (funcall (foo this that) this that).
At least, that is a much stronger indication ...
| If you lookup (or even compute!) a function based on different
| criteria than the parameters to it, then a g-f won't buy you much.
Which is why I said "begin to suspect" and not "conclude".
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
In article <···············@shuttle.math.ntnu.no>,
Harald Hanche-Olsen <······@math.ntnu.no> wrote:
> + Rahul Jain <·····@nyct.net>:
>
> | Just like the word "record" has different meaning when used as a
> | verb vs. a noun, a lisp symbol or expression can have different
> | meanings when used as an operator vs. a variable.
>
> A symbol yes, but an expression? Variables have SYMBOL-VALUE and
> SYMBOL-FUNCTION, but an expression like (foo bar) doesn't have that
> distinction, so I don't see a /technical/ reason why
>
> ((foo bar) this that)
>
> couldn't be syntactic sugar for
>
> (funcall (foo bar) this that)
>
> But perhaps nobody felt a need for it, and maybe they thought the
> funcall version is clearer anyhow. Personally, I have no problem with
> having to write the occasional FUNCALL, and it does point out very
> clearly to the reader that something special is going on. (If I ever
> see a FUNCALLs of the above sort in the code, I would begin to suspect
> that the writer was unfamiliar with generic functions.)
Maclisp had an option that you could set that would cause it to try to
evaluate the function position of an expression if it wasn't a valid
function name or lambda expression. As far as I recall, it was rarely
used.
Other Lisps have allowed programmers to extend what's allowed in the
function position. Zetalisp had "lambda macros", which are macros that
could be used in the place where LAMBDA appears in an expression like:
((lambda (x) (+ x 1)) 3)
or
(function (lambda ...))
I think they used this as the underlying mechanism to support lots of
extended function name notations, such as #'(setf <place>) and
#'(:METHOD <flavor-name> <message-name>).
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Pascal Costanza
Subject: Re: why funcall is needed in things like ((foo) 10)
Date:
Message-ID: <4olbe4Ff3p1uU1@individual.net>
Harald Hanche-Olsen wrote:
> + Rahul Jain <·····@nyct.net>:
>
> | Just like the word "record" has different meaning when used as a
> | verb vs. a noun, a lisp symbol or expression can have different
> | meanings when used as an operator vs. a variable.
>
> A symbol yes, but an expression? Variables have SYMBOL-VALUE and
> SYMBOL-FUNCTION, but an expression like (foo bar) doesn't have that
> distinction, so I don't see a /technical/ reason why
>
> ((foo bar) this that)
>
> couldn't be syntactic sugar for
>
> (funcall (foo bar) this that)
>
> But perhaps nobody felt a need for it, and maybe they thought the
> funcall version is clearer anyhow.
It would actually create semantic ambiguities. Consider that (foo bar)
is a macro invocation that expands to a symbol, say, 'baz. Should the
result then be equivalent to (baz this that) or (funcall baz this that)?
Or worse: Consider that (foo bar) is a function that returns a symbol?
Should that be rejected, or should that also be handled more
"conveniently"? Recall that (funcall 'baz this that) is well defined...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza escreveu:
> Or worse: Consider that (foo bar) is a function that returns a symbol?
> Should that be rejected, or should that also be handled more
> "conveniently"? Recall that (funcall 'baz this that) is well defined...
good point.
Pedro Kroger
+ Pascal Costanza <··@p-cos.net>:
| Harald Hanche-Olsen wrote:
|> so I don't see a /technical/ reason why
|> ((foo bar) this that)
|> couldn't be syntactic sugar for
|> (funcall (foo bar) this that)
|
| It would actually create semantic ambiguities. Consider that (foo
| bar) is a macro invocation that expands to a symbol, say,
| 'baz. Should the result then be equivalent to (baz this that) or
| (funcall baz this that)?
Yeah, one would have to make a decision, and for consistency's sake,
the second option seems better. But it's not really /right/ either,
given how we're used to thinking of macro invocations as mere textual
replacement (at least, I'm used to thinking that way).
| Or worse: Consider that (foo bar) is a function that returns a symbol?
| Should that be rejected, or should that also be handled more
| "conveniently"? Recall that (funcall 'baz this that) is well
| defined...
I actually think your first objection is the more serious one. I
don't see any problem with the second one at all: As you point out,
you can funcall a symbol, so if the form in the function position
returns a symbol, just go ahead and funcall it. Probably what the
programmer intended anyway. With the possible exception where the
symbol has a local FLET or LABELS binding, but those would be ignored
in this case, and that is as it should be.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
From: Pascal Costanza
Subject: Re: why funcall is needed in things like ((foo) 10)
Date:
Message-ID: <4ojttmFf4ahgU1@individual.net>
Pedro Kr�ger wrote:
> ·············@specastro.com escreveu:
>
>> Because (foo) returns a function object and the evaluation rules don't
>> allow a function object there.
>
> thanks for your answer. but that's sort of my point. is there any
> reason for not allowing function objects in this position in the
> evaluation rules?
Google for Lisp-1 and Lisp-2, and you will find quite a few discussions
about this.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pedro Kröger wrote:
> Hi,
>
> I understand the need to use funcall in CL; because it has different
> namespaces for functions and variables. But I don't quite understand
> the need of it for closures, like:
>
> (defun foo ()
> (lambda (x) (* x x)))
>
> (funcall (foo) 10) => 100
> ((foo) 10) => error
>
> since (foo) returns a function object, why funcall is needed?
In (funcall (foo) 10), (foo) is in the expression namespace, where
syntax is mapped to a value using evaluation.
In ((foo) 10), (foo) is in the compound function name namespace. It's
not a valid function name, but the potential for extension is there.
See? It can still be regarded as a consequence of two namespaces.