Subject: Re: syntactic bindings as first-class values?
From: (Rob Warnock)
Date: 1997/08/08
Newsgroups: comp.lang.scheme
Message-ID: <5se81c$>

Brian Harvey <bh@anarres.CS.Berkeley.EDU> wrote:
| Is it, then, just a coincidence that the things R4RS call "syntax" are
| exactly the ones whose subexpressions aren't evaluated ahead of time?

Close. I think of "syntax" as anything that doesn't obey the default
expression evaluation rule of "first, evaluate every subexpression,
then procedure-apply the value of the first subexpression to the values
the 2nd-Nth ones". This also includes things whose syntactic form isn't
even a procedure call, e.g., "let", "do", and other constructs which
contain binding subforms.

But if you ignore lexical issues (that is, if you don't consider lexical
analysis part of "syntax"), and you eliminate all the "syntactic sugar"
forms (those which can be macro-transformed into "more basic" forms) and
primitive procedures (e.g., all of the arithmetic), you're left with the
following "core syntax" forms:

	(DEFINE <variable> <value>)	; global binding
	(QUOTE <datum>)
	(LAMBDA <args> <body>)
	(IF <pred> <truebranch> <falsebranch>)
	(SET! <variable> <value>)	; mutation
	(<expr>...)			; procedure call

So it should be no surprise, then, that these are *EXACTLY* the forms
that the Scheme standard refers to as "primitive expressions" [R4RS 4.1].
This is the syntax you can't "wish away".

But of course, if you're not comfortable programming barely above the
Turing Machine level (i.e., you don't want to go blind), you need:

	(DEFINE-MACRO <args> <body>)

or equivalent, to build the rest of what people usually include in any
"useful" Scheme syntax (and, or, begin, cond, case, and all the rest),
what R4RS calls "derived expressions".

Now, is there any difference between *only* providing the "core" syntax
plus some kind of macro facility (such as "define-macro" or "defmacro") and
providing a "rich" implementation with most of the forms being primitive?
Yes, and it's not a trivial question -- there are plusses and minusses to
both. In the former case, you may lose a bit of performance; in the latter
case, you may lose quite a bit of extensibility.


Rob Warnock, 7L-551
Silicon Graphics, Inc.
2011 N. Shoreline Blvd.		Phone: 650-933-1673  FAX: 650-933-4392
Mountain View, CA  94043	PP-ASEL-IA