As someone who was *deeply* engrossed in the (quite beautiful)
SCM source code a few years back, I'd like to add some
possibly clarifying comments.
SCM does in fact contain and make heavy, central use of
some low-level, "undisciplined" macro facilities that draw
from some lisp traditions. It performs a certain amount of
on-the-fly, incremental code rewriting. In that sense, SCM
is very, very friendly to syntactic extensions using macros --
it makes heavy use of them, in one way of looking at things.
This is a very handy arrangement for someone who is willing
to hack at all levels of the system.
As I understand it, the complaint here is that the
goal of standardizing features related to hygenic macros
has evolved into design constraints that are out of proportion
and that are playing out, in the draft, in ways that show a
lack of foresight and/or concern about some valuable implementation
techniques.
-t
Aubrey Jaffer wrote:
> 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.
>
> _______________________________________________
> r6rs-discuss mailing list
> r6rs-discuss_at_lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>
>
Received on Tue Mar 06 2007 - 16:24:13 UTC