Please explain the below errors:
guile> (((lambda (a) (lambda (b) (list a b))) 1) 2)
(1 2)
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006
[1]> (((lambda (a) (lambda (b) (list a b))) 1) 2)
*** - EVAL: ((LAMBDA (A) (LAMBDA (B) (LIST A B))) 1) is not a function
name; try using a symbol
instead
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead.
ABORT :R2 ABORT
Similar errors in emacs lisp.
Thanks a lot in advance
gnuist
Sorry, guile is scheme. So no error in guile but errors are
gotten in clisp and emacs.
On Oct 6, 10:34 pm, ·········@hotmail.com wrote:
> Please explain the below errors:
>
> guile> (((lambda (a) (lambda (b) (list a b))) 1) 2)
> (1 2)
>
> i i i i i i i ooooo o ooooooo ooooo ooooo
> I I I I I I I 8 8 8 8 8 o 8 8
> I \ `+' / I 8 8 8 8 8 8
> \ `-+-' / 8 8 8 ooooo 8oooo
> `-__|__-' 8 8 8 8 8
> | 8 o 8 8 o 8 8
> ------+------ ooooo 8oooooo ooo8ooo ooooo 8
>
> Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
> Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
> Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
> Copyright (c) Bruno Haible, Sam Steingold 1999-2000
> Copyright (c) Sam Steingold, Bruno Haible 2001-2006
>
> [1]> (((lambda (a) (lambda (b) (list a b))) 1) 2)
>
> *** - EVAL: ((LAMBDA (A) (LAMBDA (B) (LIST A B))) 1) is not a function
> name; try using a symbol
> instead
> The following restarts are available:
> USE-VALUE :R1 You may input a value to be used instead.
> ABORT :R2 ABORT
>
> Similar errors in emacs lisp.
>
> Thanks a lot in advance
> gnuist
On Oct 7, 6:36 am, ·········@hotmail.com wrote:
> Sorry, guile is scheme. So no error in guile but errors are
> gotten in clisp and emacs.
Well that's because it's an error in Lisp dialects where functions are
not first-class denotable values. I believe there's a special form
FUNCALL for dealing with this problem in that world.
I don't live there myself :)
david rush
From: Pascal Costanza
Subject: Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?
Date:
Message-ID: <5mrsqoFesppjU2@mid.individual.net>
David Rush wrote:
> On Oct 7, 6:36 am, ·········@hotmail.com wrote:
>> Sorry, guile is scheme. So no error in guile but errors are
>> gotten in clisp and emacs.
>
> Well that's because it's an error in Lisp dialects where functions are
> not first-class denotable values.
In Common Lisp (and presumably Emacs Lisp), functions are as first-class
as in Scheme and elsewhere. You just have to do a bit extra to use them
as first-class values, that's all. There aren't any fundamental
restrictions there because of that.
(In Common Lisp, you also get lexical scoping by default, so you get
what you expect if you come from a functional programming background.)
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/
From: Pascal Costanza
Subject: Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?
Date:
Message-ID: <5mrsliFesppjU1@mid.individual.net>
·········@hotmail.com wrote:
> Please explain the below errors:
> [1]> (((lambda (a) (lambda (b) (list a b))) 1) 2)
>
> *** - EVAL: ((LAMBDA (A) (LAMBDA (B) (LIST A B))) 1) is not a function
> name; try using a symbol
> instead
> The following restarts are available:
> USE-VALUE :R1 You may input a value to be used instead.
> ABORT :R2 ABORT
>
>
> Similar errors in emacs lisp.
Common Lisp (and presumably Emacs Lisp) is a Lisp-2, which means that
function positions are evaluated differently than value positions. In
order to treat a first-class value as a function, you have to shift it
via FUNCALL. In order to yield a function as a first-class value, you
have look it up with FUNCTION.
Your code works in Common Lisp when you do this:
(funcall (funcall (lambda (a) (lambda (b) (list a b))) 1) 2)
This looks inconvenient, but there are good reasons why one might prefer
a Lisp-2 over a Lisp-1 (like Scheme). See
http://www.dreamsongs.com/Separation.html
If you google for Lisp-2 and Lisp-1, you will find more information.
There have been a number of discussions about this in comp.lang.lisp.
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/
On Oct 7, 12:02 pm, Pascal Costanza <····@p-cos.net> wrote:
> Common Lisp (and presumably Emacs Lisp) is a Lisp-2, which means that
> function positions are evaluated differently than value positions.
Now I may be demonstrating a certain amount of historical ignorance
here, but I was under the impression that Lisp-2 referred to the fact
that there were effectively to different *name* spaces, one in which
'ordinary' values were bound and one in which 'callable' values were
bound. However, this text:
> order to treat a first-class value as a function, you have to shift it
> via FUNCALL. In order to yield a function as a first-class value, you
> have look it up with FUNCTION.
Makes it sound like there are two fundamentally different *types* of
values And FUNCALL and FUNCTION are the type cast operators between
those types. Is this a valid way of looking at this?
david rush
--
opinionated git
David Rush quoting a Common Lisp programmer:
> > order to treat a first-class value as a function, you have to shift it
> > via FUNCALL. In order to yield a function as a first-class value, you
> > have look it up with FUNCTION.
>
> Makes it sound like there are two fundamentally different *types* of
> values And FUNCALL and FUNCTION are the type cast operators between
> those types. Is this a valid way of looking at this?
No, but that invalid way of looking at it may be
common among Common Lisp programmers.
What's really going on is that Common Lisp,
as a Lisp-2, needs some way to distinguish
the environment in which variables are to be
resolved. That's the purpose of FUNCTION.
Then, to avoid the syntactic clutter of using
FUNCTION in the operator expression of
almost every call, Common Lisp evaluates
operator expressions differently from operand
expressions.
If you can regard higher-order functions as
unnatural, then you can regard Common Lisp's
semantics as natural. That's the real lesson
of the Gabriel/Pitman paper cited earlier in
this thread. By the way, that paper was not
subject to normal peer review; it was political
from the start, and its conclusion that the
advantages and disadvantages of Lisp-1 and
Lisp-2 are comparable was pre-ordained.
To reach that conclusion, they had to count
at least one of the arguments against Lisp-2
as an argument in favor of Lisp-2. I won't
spoil your fun by explaining this; it's obvious
if you read the paper carefully with an open
mind.
Will
In article <························@57g2000hsv.googlegroups.com>,
William D Clinger <········@yahoo.com> wrote:
> David Rush quoting a Common Lisp programmer:
> > > order to treat a first-class value as a function, you have to shift it
> > > via FUNCALL. In order to yield a function as a first-class value, you
> > > have look it up with FUNCTION.
> >
> > Makes it sound like there are two fundamentally different *types* of
> > values And FUNCALL and FUNCTION are the type cast operators between
> > those types. Is this a valid way of looking at this?
>
> No, but that invalid way of looking at it may be
> common among Common Lisp programmers.
No.
>
> What's really going on is that Common Lisp,
> as a Lisp-2, needs some way to distinguish
> the environment in which variables are to be
> resolved. That's the purpose of FUNCTION.
>
> Then, to avoid the syntactic clutter of using
> FUNCTION in the operator expression of
> almost every call, Common Lisp evaluates
> operator expressions differently from operand
> expressions.
>
> If you can regard higher-order functions as
> unnatural,
Huh?
> then you can regard Common Lisp's
> semantics as natural. That's the real lesson
> of the Gabriel/Pitman paper cited earlier in
> this thread. By the way, that paper was not
> subject to normal peer review; it was political
> from the start, and its conclusion that the
> advantages and disadvantages of Lisp-1 and
> Lisp-2 are comparable was pre-ordained.
>
> To reach that conclusion, they had to count
> at least one of the arguments against Lisp-2
> as an argument in favor of Lisp-2. I won't
> spoil your fun by explaining this; it's obvious
> if you read the paper carefully with an open
> mind.
>
> Will
I don't think above gives a valid impression what
Common Lisp users think about the topic.
I also don't think 'natural' and 'unnatural' are
adjectives I would attribute to features of programming
languages.
As your very own post shows 'religion' is involved.
Well, yes, I vastly prefer the Common Lisp way,
and I especially dislike Scheme code like
((((((lambda (..) ...) ....)))))
It is one of the greatest code obfuscation methods.
Common Lisp forces one to add FUNCALLs to make
function calls explicit in these cases. I see
that as something that increases readability of code.
--
http://lispm.dyndns.org
From: Pascal Costanza
Subject: Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?
Date:
Message-ID: <5mu1pvFevrusU2@mid.individual.net>
William D Clinger wrote:
> If you can regard higher-order functions as
> unnatural, then you can regard Common Lisp's
> semantics as natural. That's the real lesson
> of the Gabriel/Pitman paper cited earlier in
> this thread. By the way, that paper was not
> subject to normal peer review; it was political
> from the start, and its conclusion that the
> advantages and disadvantages of Lisp-1 and
> Lisp-2 are comparable was pre-ordained.
>
> To reach that conclusion, they had to count
> at least one of the arguments against Lisp-2
> as an argument in favor of Lisp-2. I won't
> spoil your fun by explaining this; it's obvious
> if you read the paper carefully with an open
> mind.
Whatever. Lisp-1 just sucks. ;-)
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/
On 8 out, 03:42, Pascal Costanza <····@p-cos.net> wrote:
> Whatever. Lisp-1 just sucks. ;-)
Lisp2 is insane and verbose. There's nothing more natural than having
functions as first-class values and as simple a rule as saying "car of
an evaluated list is a function". No obfuscation nor confusion
whatsoever.
You know, it'd be much more worthwhile for the Lisp community to at
least think about having more up-to-date paradigms -- like function
definition by pattern-matching and function/operator overloading (that
would be much better than 1 or 2 namespaces) -- rather than engage in
these useless pissing-contests. The Common Lisp standard is from
when, again?
At least Scheme has come up with a fresh new R6RS and has had the SRFI
process for quite some years now...
From: Pascal Costanza
Subject: Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?
Date:
Message-ID: <5mvjc8Ff5mn8U1@mid.individual.net>
namekuseijin wrote:
> On 8 out, 03:42, Pascal Costanza <····@p-cos.net> wrote:
>> Whatever. Lisp-1 just sucks. ;-)
>
> Lisp2 is insane and verbose. There's nothing more natural than having
> functions as first-class values and as simple a rule as saying "car of
> an evaluated list is a function". No obfuscation nor confusion
> whatsoever.
I see. :)
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/
From: Don Geddis
Subject: Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?
Date:
Message-ID: <87d4vpv34c.fsf@geddis.org>
William D Clinger <········@yahoo.com> wrote on Sun, 07 Oct 2007:
> By the way, that paper was not subject to normal peer review; it was
> political from the start, and its conclusion that the advantages and
> disadvantages of Lisp-1 and Lisp-2 are comparable was pre-ordained.
Sure, that makes sense.
> That's the real lesson of the Gabriel/Pitman paper cited earlier in this
> thread. To reach that conclusion, they had to count at least one of the
> arguments against Lisp-2 as an argument in favor of Lisp-2. I won't spoil
> your fun by explaining this; it's obvious if you read the paper carefully
> with an open mind.
I've read the paper many times, and I'm unable to identify what you're
referring to. Perhaps I don't have an open mind. In any case, what argument
"against" Lisp-2 is incorrectly counted as an argument "in favor" of Lisp-2?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
If a kid asks where rain comes from, I think a cute thing to tell him is "God
is crying." And if he asks why God is crying, another cute thing to tell him
is "Probably because of something you did." -- Deep Thoughts, by Jack Handey
From: .
Subject: Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?
Date:
Message-ID: <47098474$0$24258$4c368faf@roadrunner.com>
On Sun, 07 Oct 2007 23:27:20 +0000, David Rush wrote:
> Makes it sound like there are two fundamentally different *types* of
> values And FUNCALL and FUNCTION are the type cast operators between
> those types. Is this a valid way of looking at this?
>
> david rush
An expression needs a symbol as it's car. If the symbol has a
function-value, that function is called. If you want to call a function
that isn't bound to a symbol, you use FUNCALL. In pseudo-scheme
is might be defined is (lambda (f args) (f args)). FUNCTION is the accessor
for the function-value of a symbol.
In article <·························@roadrunner.com>,
"." <···@bar.biz> wrote:
> On Sun, 07 Oct 2007 23:27:20 +0000, David Rush wrote:
> > Makes it sound like there are two fundamentally different *types* of
> > values And FUNCALL and FUNCTION are the type cast operators between
> > those types. Is this a valid way of looking at this?
> >
> > david rush
>
> An expression needs a symbol as it's car. If the symbol has a
> function-value, that function is called. If you want to call a function
> that isn't bound to a symbol, you use FUNCALL. In pseudo-scheme
> is might be defined is (lambda (f args) (f args)). FUNCTION is the accessor
> for the function-value of a symbol.
Which language are you talking about? Certainly not Common Lisp.
--
http://lispm.dyndns.org
From: Pascal Costanza
Subject: Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?
Date:
Message-ID: <5mu1klFevrusU1@mid.individual.net>
David Rush wrote:
> On Oct 7, 12:02 pm, Pascal Costanza <····@p-cos.net> wrote:
>> Common Lisp (and presumably Emacs Lisp) is a Lisp-2, which means that
>> function positions are evaluated differently than value positions.
>
> Now I may be demonstrating a certain amount of historical ignorance
> here, but I was under the impression that Lisp-2 referred to the fact
> that there were effectively to different *name* spaces, one in which
> 'ordinary' values were bound and one in which 'callable' values were
> bound.
This is correct. However, the namespace for ordinary values may also
contain callable values, whereas the namespace for callable values may
contain callable values only.
> However, this text:
>
>> order to treat a first-class value as a function, you have to shift it
>> via FUNCALL. In order to yield a function as a first-class value, you
>> have look it up with FUNCTION.
>
> Makes it sound like there are two fundamentally different *types* of
> values And FUNCALL and FUNCTION are the type cast operators between
> those types. Is this a valid way of looking at this?
No, and I am sorry if I have given that impression.
Still, the function namespace may contain only callable values, and in
that regard that namespace is indeed typed. This is why this may be
confusing.
But it is in fact much simpler:
(let ((foo 42))
(flet ((foo (x) (print x)))
(foo foo)))
This code binds 42 to foo in the value namespace, and a function to foo
in the function namespace. The first position in the expression (foo
foo) looks up the latter, the second position looks up the former.
Overall, the whole expression prints 42.
This is all there is to this: The first position is looked up in a
different namespace than all the other positions.
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/
> [1]> (((lambda (a) (lambda (b) (list a b))) 1) 2)
>
> *** - EVAL: ((LAMBDA (A) (LAMBDA (B) (LIST A B))) 1) is not a function
> name; try using a symbol
> instead
As the others have already told you, you can't just put any arbitrary
expression in the CAR of a form to be evaluated. Now, it's not quite
true that you can only use symbols in the CAR of evaluated forms,
either, because you can also put a lambda expression there. Note that
by this I do not mean just any expression that evaluates to a function
object, but really simply a lambda expression: a list whose CAR is the
symbol LAMBDA (and which can be evaluated to a function object). So
the following is valid and will yield 10:
((lambda (x) x) 10)
But the following is invalid (assuming you haven't defined a function
called FOO elsewhere):
(let ((foo (lambda (x) x)))
(foo 10))
Note also that when in an evaluated position, (function (lambda ...))
and (lambda ...) are equivalent, but you can't use the former as the
CAR of a form to be evaluated, because it isn't a lambda expression.
I just wanted to mention this, because you may have already stumbled
upon it when experimenting, and the fact that (((lambda () (lambda
())))) is invalid while ((lambda ())) isn't may be confusing you
needlessly. The point is that you should ignore the fact that
((lambda ())) works and pretend that it doesn't until you understand
why it's a special case.
~ Matthias
In article <························@k79g2000hse.googlegroups.com>,
Matthias Benkard <··········@gmail.com> wrote:
> > [1]> (((lambda (a) (lambda (b) (list a b))) 1) 2)
> >
> > *** - EVAL: ((LAMBDA (A) (LAMBDA (B) (LIST A B))) 1) is not a function
> > name; try using a symbol
> > instead
>
> As the others have already told you, you can't just put any arbitrary
> expression in the CAR of a form to be evaluated. Now, it's not quite
> true that you can only use symbols in the CAR of evaluated forms,
> either, because you can also put a lambda expression there. Note that
> by this I do not mean just any expression that evaluates to a function
> object, but really simply a lambda expression: a list whose CAR is the
> symbol LAMBDA (and which can be evaluated to a function object).
I think what has made this more confusing than it was in the days of
Maclisp was the introduction of the LAMBDA macro. Now (lambda ...)
evaluates to a function, so when you put a lambda expression in the CAR
of a form it looks like the CAR is being evaluated, which suggests the
assumption that any expression can be put there to be evaluated (with
the special case that symbols are looked up in the function namespace).
--
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: David Trudgett
Subject: Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?
Date:
Message-ID: <pan.2007.10.07.07.38.30.321328@yahoo.com>
On Sun, 07 Oct 2007 05:34:29 +0000, gnuist006 wrote:
> Please explain the below errors:
>
<snip>
> [1]> (((lambda (a) (lambda (b) (list a b))) 1) 2)
>
> *** - EVAL: ((LAMBDA (A) (LAMBDA (B) (LIST A B))) 1) is not a function
The reason is that ((LAMBDA (A) (LAMBDA (B) (LIST A B))) 1) is not a
function, it is a list. If you try this instead, it will work:
(funcall ((lambda (a) (lambda (b) (list a b))) 1) 2) => (1 2)
Cheers,
David Trudgett