[plt-scheme] macros, special forms, and lazy functions
Stephen Bloch wrote:
> As far as my beginning students are concerned, "and" and "or" are
> functions with contract
> Boolean Boolean ... -> Boolean
> They happen to be "smart" about their arguments, not bothering to
> evaluate the later arguments if the earlier arguments answer the question.
If I were a student, I would wonder how to write such a smart function
myself -- could I write a smart `product' that didn't bother to evaluate
later arguments as soon as it found a 0? I already know I can't write a
n-ary function, so I'd settle for a smart binary product.
> But in fact, they're implemented as macros or special forms. (Is there
> a difference between a macro and a special form?) Which makes no
> difference in BSL, BSLLA, or ISL, but once we get to ISLL, it makes a
> difference: one cannot pass "or" or "and" as arguments to a function
> that expects a function.
ISL is higher-order, it just does not include an nameless function
constructor and requires variable names to appear in operator position
of function applications.
You can imitate (lambda (x) e) with:
(local [(define (f x) e)] ; where f not in e.
f)
And ((f x) y) with:
(local [(define g (f x))]
(g y))
So the fact that `and' and `or' are not values can be observed as early
as ISL (disregarding the fact that the "smartness" can be observed from
the beginning).
In ISL, you can do this:
(define f add1)
(f 0)
So if `and' were a value, you should be able to do:
(define g and)
(g true)
But you cannot in ISL.
I find it simpler and easier to convey that there is 1) function
application, which has a uniform evaluation process, and there are 2)
other expression forms, which have specialized evaluation processes.
The word "macro" shouldn't come into play -- macros are an
implementation strategy for extending the set of special forms (compound
expressions that are not function application). Every language has
function application and special forms. Not every language has "smart"
functions or macros. Since HtDP is about designing programs in any
language, these kind of particulars should be avoided.
David