RE: What's so cool about Scheme?

[Mike Newhall <address@hidden>]

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.  This might require some further manipulation like turning the argument into a string, concatenating it to the 'function string', then evaling the whole thing, but it would work, after a fashion.  It's also something you can't do directly in a language like C that doesn't have code=data.

>> 	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.

	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.