RE: What's so cool about Scheme?

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

Mike Newhall wrote:
> At 03:18 PM 2003.06.03 -0400, Anton van Straaten wrote:
> >There's no reason that a
> >language that can treat source code as data, and evaluate it at
> >runtime, has to have higher order functions.  Some languages
> >have worked like this, although I can only think of older ones:
> >some versions of BASIC and dBASE, for example.
>
> 	I think it follows naturally, if crudely.  Let's say I have
> a language that allows me to eval a character string: I can now
> define a 'map' function that takes a string representing the
> function to apply, and 'eval' it for each element.

I agree that eval gives you crude HO "functions" - although they're not
first-class functions in the sense that they aren't indistinguishable from
functions implemented directly in the language.  However, the only way that
I see this leading to "higher-order functions as a natural side-effect of
code=data" is that if people start using eval in the way you suggest, they'd
very soon be clamoring for a better feature, which proper HO functions could
provide.

> 	As I understand the FUNARG problem, you do need closures,
> or at least, you want them.  The definition of the FUNARG problem
> is the problem that occurs when you evaluate source code in a
> different environment than it was defined in: variables occuring
> in the source now bind to local bindings within the higher-order
> function, possibly masking the true lexical (or even dynamic)
> bindings that were intended by the author of the source.
> Closures / lambda solve this problem by bundling code with it's
> definition environment.

Unless the language being eval'd already has a funarg problem without eval
being involved, eval alone doesn't necessarily introduce that problem
(possibly depending on how the language implements eval).

To take Scheme's eval as a fairly typical example, there's no interaction
between eval'd code and the lexical environment in which it is evaluated -
the only interaction is with the dynamic, global environment.  This is not
affected by the funarg problem.

In a language with non-global variables with dynamic scope, it's easy enough
for an eval feature to allow evaluated code to bind to those dynamic
variables.  When evaluating a piece of code, that binding can be made to
work perfectly well.  The funarg problem would only arise if the evaluated
code resulted in some kind of function object which could be passed outside
the context in which the evaluation occurred.  However, if such an object
exists in the language, the language already has a funarg problem, without
eval having introduced it.

So, I still maintain there's no technical connection between a language
having eval, and the need for higher-order functions or closures.

Anton