[r6rs-discuss] Interpreters need not apply?

From: Aubrey Jaffer <agj>
Date: Tue Mar 6 12:55:55 2007

By requiring phased processing of libraries, R5.92RS has
disenfranchised "pure interpreters", apparently for the sake of
macros.

Macros are supposed to provide syntax extension, but it is a limited
notion of syntax. Macros aren't sufficient to define "." to be
dot-product, to implement infix notation, or to make
#2A:floC32b((34.2+2.7i 3.2) (0.1 0.0)) the syntax for a uniform
complex 2-dimensional array.

With languages changing over time, a program or library working at one
point in time is no longer good enough; its source must be
maintainable in order to track language and library changes.

The use of macros to modify or introduce new syntactic forms reduces
the readability of program source. In the presence of nonstandard
syntax, one can't be sure whether a given pair of parentheses delimits
an expression, pattern, or binding, or of the lexical environment it
might eventually be executed in.

New control features do not necessarily require new syntax. Values,
call-with-values, and dynamic-wind, added in R5RS, are all procedures.
The use of lambda in arguments to procedures establishes binding
scope, no matter what those procedures do.

Although the motivation for Scheme macros may have been to reduce the
number of primitive forms, its effect has been the proliferation of
mutually incomprehensible language dialects, as though R5RS was not
sufficient in itself for all varieties of programming.

Oleg Kiselyov created his own language implemented by more than 2
dozen macros; code from his postings doesn't run in plain R5RS.
`When' is one of his macros:

  (when condition . stmts)

He translates it to

  (and condition (begin . stmts))

But section 13.1 "When and Unless" (page 53) of r6rs-lib_92 translates
it to the equivalent of

  (cond (condition . stmts))

"(when condition . stmts)" is a savings of 2 characters over
"(cond (condition . stmts))". Introducing a new syntax to save 2
characters is absurd. Oleg's macro is not compatible with section
13.1. That such a simple syntax is not easily standardized is further
evidence that this enterprise is wrong-headed.

Using the same mechanism for Report mandated syntactic forms and user
macros means that macro-expanding an expression is likely to return a
bloated, unrecognizable mess. In contrast, macroexpand in CommonLisp
is useful because it leaves special forms alone, expanding only the
macros.

The code in SLIB modules is written avoiding the gratuitous use of
macros [precedence-parse and schmooz use fluid-let, which will
probably get replaced by dynamic-wind]. SLIB and the complicated
applications JACAL and FreeSnell show that Scheme without macros is
sufficient for a wide variety of computations.

If built-in syntactic forms are not rebound, SLIB's module protocol is
sufficient for this curated library system. Most of the novelty which
the R6RS module system supports is what I argue above is bad practice:
private dialects, which are difficult to maintain.

As R6RS stands, reimplementing SCM to hew to R6RS would require a lot
of effort for features I view indifferently or negatively, while not
standardizing or even supporting as a library (read) syntax the one
feature, multidimensional arrays, which Scheme desparately lacks.

For those reasons I doubt that SCM will be rewritten to support R6RS.
SCM and the many unsupported or weakly supported Scheme
implementations will remain and call themselves Scheme for years to
come.

Because R6RS is a major incompatible change from earlier Reports, it
should refer to itself as Scheme6 in the report. Otherwise, the
confusion between Scheme and Scheme6 will be another reason for people
to not choose Scheme.
Received on Tue Mar 06 2007 - 12:55:21 UTC