Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[gnuist006]

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

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[gnuist006]

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

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[David Rush]

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

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[Pascal Costanza]

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

-- 
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[Pascal Costanza]

gnuist006@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/

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[David Rush]

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

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[.]

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.

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[Rainer Joswig]

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

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[William D Clinger]

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

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[Pascal Costanza]

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/

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[namekuseijin]

On 8 out, 03:42, Pascal Costanza <p...@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...

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[Pascal Costanza]

namekuseijin wrote:
> On 8 out, 03:42, Pascal Costanza <p...@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/

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[Don Geddis]

William D Clinger <cesura17@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/               don@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

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[Pascal Costanza]

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

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[Matthias Benkard]

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

Re: Nested Lambda function gives error in common lisp, guile, emacs lisp but works in scheme. Why?

[Barry Margolin]

In article <1191802159.161767.239420@k79g2000hse.googlegroups.com>,
 Matthias Benkard <mulkiatsch@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, barmar@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 ***