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, gnuist...@hotmail.com wrote:
[..]

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

On Oct 7, 6:36 am, gnuist...@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

gnuist006 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

David Rush wrote:
> On Oct 7, 6:36 am, gnuist...@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

On Oct 7, 12:02 pm, Pascal Costanza <p> 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

> [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

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.

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 <1191812295.692215.113710>,
William D Clinger <cesura17> 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.

In article <47098474$0$24258$4c368faf>,
"." <foo> 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.

David Rush wrote:
> On Oct 7, 12:02 pm, Pascal Costanza <p> 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

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

In article <1191802159.161767.239420>,
Matthias Benkard <mulkiatsch> 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).