RE: What's so cool about Scheme?

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

Mike Newhall wrote:
> 	Yes, perhaps this is exactly it.  You can trivially
> implement a form of higher-order functions with just code=data,
> but it will not be satisfactory; so as a language designer you'd
> better provide proper HOF's or all programs will be littered with
> this hack!

I can sort of agree with that, but really, without closures, people will -
and do - use all sorts of hacks anyway - objects, for example ;o)  Closures
are a Good and Useful Thing, independent of eval.  Eval just happens to
provide one possible way to work around lack of closures - I'd rather use
objects, though.

> 	But this precludes lexically binding with variables in the
> definition environment, a natural thing to want to do.  This is I
> think a good reason why closures are necessary.
...
> 	It's easy to bind to the *current* dynamic environment, but
> what about the dynamic environment at the point of definition?
> Since the function argument might be evaluated any number of
> levels deep, the only real way I can see to do it is to capture
> the dynamic environment at the point of definition, a separate
> good reason to have closures.

I'm not understanding how you're relating this to eval.  Certainly, an eval
capability will be more powerful in the presence of closures, but that's
because a language with closures is more powerful than one without, it
doesn't have anything to do with eval itself.

If you're saying there's more to it than that, perhaps you could give a code
or pseudocode example where e.g. the presence of eval leads to the funarg
problem existing, where it doesn't exist without eval.

> 	In summary having *just* code=data without closures, like
> the original LISP, causes all kinds of problems.

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.

Anton