[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: What's so cool about Scheme?

   From: "Anton van Straaten" <anton@appsolutions.com>
   To: "Mike Newhall" <mike@newhall.net>
   Cc: <ll1-discuss@ai.mit.edu>
   Subject: RE: What's so cool about Scheme?
   Date: Wed, 4 Jun 2003 02:46:01 -0400
   Importance: Normal
   Mike Newhall wrote:
   > At 12:18 AM 2003.06.04 -0400, Anton van Straaten wrote:
   > >This is what I've been arguing against.  I don't see how
   > code=data without closures leads to funarg problems, unless
   > the language already has a funarg problem.
   > 	If you have code=data, and no proper closures, and you want
   > some higher-order functionality, you will be forced to pass code
   > as data as functional arguments.  A natural thing to want to do
   > is to reference a local variable in that functional argument
   > external to that functional argument.  The only way to do that is
   > to capture the environment at the location the functional
   > argument is defined, and a closure does that.  It seems to me
   > then that if you naively start out with a language that has only
   > code=data (like old LISP), you will at some point want to extend
   > that language with closures to fix this problem (as Scheme did).
   > I don't see why this is such a controversial point.
   It's partly been a terminology issue.  I think I understand you better now.
   Old LISP didn't work the way you seem to be describing.  In original LISP,
   there was a LAMBDA construct which when evaluated, created a first-class
   function which could be stored in variables, passed to and from functions,

On the contrary.  In original Lisp, LAMBDA expressions
were not evaluable constructs at all.  Instead, one


Only later, when this piece of list structure beginning
with the symbol LAMBDA was applied to an argument, was the
list structure regarded as code and an execution environment
imputed to it.  This delay in regarding the list structure
as code was the entire source of the FUNARG problem.

--Guy Steele