[r6rs-discuss] [Formal] (r6rs base) must also export _ and ... at level 1

From: R. Kent Dybvig <dyb>
Date: Thu Jan 25 09:43:15 2007

I'm responding as a user/implementor, not as an editor.

> Example of useful things:
>
> - If you do not bind _ in (r6rs base), a user cannot easily create an
> r5rs-compatibility library where syntax-rules treats _ as an
> ordinary variable.

Good point.

> - If you do not bind => in (r6rs base), a teacher cannot easily create
> a teaching language in which cond does not recognize => clauses
> (PLT contains such a language).

Okay. (Nitpicking, however, you'd probably want to rule out the "or"
clause syntax and require an else clause as well, so a complete
redefinition of cond would probably be in order, and it would not be very
complicated.)

Another example is that one might want to rename all of the exports of
a library, say to counterparts in some other natural language. For
example, one might want to use ondcay, elsay, asiquotequay, unquotay, and
unquotay-icingsplay in place of cond, else, quasiquote, unquote, and
unquote-splicing. If bindings for else, unquote, and unquote-splicing are
not included in the (r6rs base) exports, this can't be done.

I don't mind requiring (r6rs base) exports for unquote, unquote-splicing,
else, =>, ..., and _, with the latter two exported for expand. Presumably
references to any of these outside of their allowed contexts should be a
syntax violation.

I wonder, however, about requiring the records library to export all of
the literals required by the define-record-type syntax: at least fields,
mutable, immutable, parent, protocol, sealed, opaque, and nongenerative.
More importantly, I wonder about requiring programmers who wish to name
imports explicitly to name all of these.

A potentially bigger issue is that some of these names are common enough
that people are likely to stomp on them by accident and be frustrated when
define-record-type reports a syntax error for input that is apparently
well formed. Furthermore, in contrast with else (in cond), unquote, =>,
etc., the define-record-type literals do not appear in contexts where
arbitrary identifier references can legitimately appear.

For such literals, should we consider using symbolic equivalence, e.g.,
recognize the literal 'fields' as such even if 'fields' has some different
binding from its binding (or non-binding) in (r6rs library)? This would
prevent us from doing some of the "useful things" above, but it might save
more than a compensating amount of grief. Should we do the same for else
in case, which can appear only where it cannot be confused for an
identifier reference?

Kent
Received on Thu Jan 25 2007 - 09:42:41 UTC