RE: What's so cool about Scheme?

["Anton van Straaten" <address@hidden>]

Mike Newhall wrote:
> At 08:23 PM 2003.06.03 -0400, Anton van Straaten wrote:
...
> >The original Lisp had first class functions, but didn't implement
> >closure behavior correctly.  It would have had the funarg problem
> >even if it didn't have eval.
>
> 	True, my point always was that once you have code=data
> without closures, you automatically get the funarg problem,
> regardless of whether there are first-class functions.

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.

I think you have it backwards, and that it's only once a language has
first-class functions that you encounter any funarg problems, if the
language doesn't have a proper closure implementation.

Using eval to simulate first-class functions doesn't create the problem,
because you're dealing with either a source representation (e.g. a string)
which can contain no active binding information, or with the result of
evaluating that source in some context.

Without "real" closures, there's no intermediate object that contains active
binding information, the way a closure does.  You could get perverse and
e.g. create an expression string that references a variable with dynamic
scope, then try to evaluate that string outside that scope.  But that's not
a funarg problem, that's just an error.  Funarg problems occur when a
variable has a valid binding in a particular context, and then loses that
binding when the code is evaluated elsewhere.

To make this as concrete as possible, this Scheme:

  (define (foo x) '(x * 2))
  (eval (foo 5))

or this Javascript:

  function foo(x) { return "x * 2"; }
  eval( foo(5) );

...does not illustrate a potential funarg problem, since there's never a
time during which the 'x' in the Scheme list, or the Javascript string, has
a valid binding.  And if you evaluate the strings within the functions,
you're left with a final value which can't suffer from a funarg problem.

Anton