From: ·······@ziplip.com
Subject: Re: functions as lists
Date: 
Message-ID: <MDELN3J3GLCKF1KBEDCLOAIBGHOPELDSHQDWEOCD@ziplip.com>
Kent M Pitman wrote:

> 
> The most obvious problem with representing a function as a list is that
> it doesn't accomodate closure.  That is,
> 
>  (DEFUN FOO (X)
>    (LAMBDA (Y) (+ X Y)))
> 
> can't return
> 
>  (LAMBDA (Y) (+ X Y))
> 
> because there's no place to remember the value that X had at the
> time of creation of executing the form that should have created a closure.
> 
> So I'm not sure really what you're asking.

I see what you are saying. Problems with closures.
I have this old book called LISP manual (sic) that talks about
how functions are lists that start with LAMBDA. That's what got
me interested in Lisp originally. I thought the advantage
of this approach was that code was literally data. No messing
around with other stuff is required. Compilation can be done
just-in-time without having to bother the programmer, just like
garbage collection makes it unnecessary to worry about low-level 
memory mangagement issues. 

Closures .... Hmmm... We obviously want

(LET ((X 7)) (LAMBDA (Y) (+ X Y)))

to become

(LAMBDA (X) (+ X 7))

Can't Lisp do this? There are tranformation rules in Lambda 
Calculus just for this kind of thing.

420

From: Thomas F. Burdick
Subject: Re: functions as lists
Date: 
Message-ID: <xcv3cf6ddqj.fsf@firestorm.OCF.Berkeley.EDU>
·······@ziplip.com writes:

> Closures .... Hmmm... We obviously want
> 
> (LET ((X 7)) (LAMBDA (Y) (+ X Y)))
> 
> to become
> 
> (LAMBDA (X) (+ X 7))

No we don't, because we also want to support:

  (DEFUN MAKE-ACCESSOR-PAIR (X)
    (LET ((PLACE X))
      (LIST (LAMBDA () PLACE)
            (LAMBDA (NEW-VALUE)
              (SETQ PLACE NEW-VALUE)))))

> Can't Lisp do this? There are tranformation rules in Lambda 
> Calculus just for this kind of thing.

Lisp source code certainly is just ordinary data, and we leverage this
with macros.  If you think you really want what you're talking about
here, you should be looking at other languages.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Matthew Danish
Subject: Re: functions as lists
Date: 
Message-ID: <20030909000805.GT1454@mapcar.org>
On Mon, Sep 08, 2003 at 04:43:03PM -0700, ·······@ziplip.com wrote:
> Closures .... Hmmm... We obviously want
> 
> (LET ((X 7)) (LAMBDA (Y) (+ X Y)))
> 
> to become
> 
> (LAMBDA (X) (+ X 7))
> 
> Can't Lisp do this? There are tranformation rules in Lambda 
> Calculus just for this kind of thing.

How about:
(let ((x 7)) (lambda (y) (incf x) (+ x y)))

Said transformation rules only apply in the absence of side-effects.

Anyway, what the book probably said (or should have said) was that a
function object can be created by evaluating a list beginning with
LAMBDA (though I think that in old dialects, lists were acceptable to
FUNCALL as well).  In Common Lisp, that isn't quite true either, as the
function object is obtained by applying the special operator FUNCTION to
a lambda form.  Conveniently, the lambda form is defined to expand into
(function <lambda-form>), so you don't have to write #' or function
explicitly.

The function itself is an object of type function.  Its definition,
on the other hand, is a list.  

-- 
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Kalle Olavi Niemitalo
Subject: Re: functions as lists
Date: 
Message-ID: <87brtuxxvi.fsf@Astalo.kon.iki.fi>
Matthew Danish <·······@andrew.cmu.edu> writes:

> How about:
> (let ((x 7)) (lambda (y) (incf x) (+ x y)))

  (lambda (y)
    (incf #1=(car '(7)))
    (+ #1# y))

Not with the CL rule about modifying literal objects, though.
From: Mario S. Mommer
Subject: Re: functions as lists
Date: 
Message-ID: <fzy8wya1rd.fsf@cupid.igpm.rwth-aachen.de>
·······@ziplip.com writes:
> (LET ((X 7)) (LAMBDA (Y) (+ X Y)))
> 
> to become
> 
> (LAMBDA (X) (+ X 7))
> 
> Can't Lisp do this?

It depends what you mean by "do". Some compilers (i think CMUCL, for
instance) do it.

> There are tranformation rules in Lambda 
> Calculus just for this kind of thing.

Google for partial evaluation.

OTOH, you will surely benefit from reading a more modern book, like
Grahams's "ANSI Common Lisp", Or specially Norvigs PAIP.
From: Kent M Pitman
Subject: Re: functions as lists
Date: 
Message-ID: <sfwznherqto.fsf@shell01.TheWorld.com>
Mario S. Mommer <········@yahoo.com> writes:

> ·······@ziplip.com writes:
> > (LET ((X 7)) (LAMBDA (Y) (+ X Y)))
> > 
> > to become
> > 
> > (LAMBDA (X) (+ X 7))
> > 
> > Can't Lisp do this?

[I can't find Mike's original post to respond to, so I'm responding 
 indirectly to the text as enclosed by Mario.]

Following with this same theory, what would you have them return for:

 (LET ((X 7))
   (LIST (LAMBDA (Y) (SETQ X Y))
         (LAMBDA ()  X)))
From: Pascal Costanza
Subject: Re: functions as lists
Date: 
Message-ID: <bjk7o1$12b2$1@f1node01.rhrz.uni-bonn.de>
·······@ziplip.com wrote:

> I have this old book called LISP manual (sic) that talks about
> how functions are lists that start with LAMBDA. That's what got
> me interested in Lisp originally. I thought the advantage
> of this approach was that code was literally data. No messing
> around with other stuff is required. Compilation can be done
> just-in-time without having to bother the programmer, just like
> garbage collection makes it unnecessary to worry about low-level 
> memory mangagement issues. 

I have already pointed you to 
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-453.pdf - and I 
meant it! :)

Please read the paper, it contains a discussion about this issue (among 
other highly interesting things). See page 18ff for a discussion of your 
particular topic.


Pascal

-- 
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)