RE: What's so cool about Scheme?

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

Mike Newhall wrote:
> 	Ah, perhaps this is the rub: pure functional languages
> allow higher-order functions *and* side-effect-free programming.
> A dynamic language offers higher-order functions as a natural
> side-effect of code=data, without necessarily saying anything
> about the language's support for side-effect-free programming.

I don't see that "a dynamic language offers higher-order functions as a
natural side-effect of code=data", unless you're using the term "code =
data" differently than I understand it.

In the Lisp/Scheme context, it usually refers to "source code = data",
meaning that you can easily write programs that read, write, manipulate, and
ultimately evaluate source code (syntax).  This has very little to do with
higher-order functions, even though it's also true that "higher-order
functions = data".

I connected these two features in a message earlier today, by suggesting
that "source code = data" can be seen as an extension into the syntactic
domain of "functions = data".  But it's only the former that's usually
referred to as code=data, afaik.

In an earlier message, you addressed this by saying:

> 	I was thinking of the FUNARG prohlem; if you can pass
> around data and interpret it as code, you will run into the
> need for closures.

However, I don't see that this is the case: with "source code = data", you
will only run into the need for closures if the source code you're
evaluating creates closures, which in turn is only going to be possible if
the language already supports that feature.  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.

Anton