Re: [Scheme-reports] Plebiscite Vote: Aaron W. Hsu (yes)

[John Cowan <cowan@x>]

It's my policy not to debate vote rationales, but I believe you have
fallen into a number of factual errors and unclarities here, so I'm
writing you privately about them.

> While the WG1 made the arguable decision of altering the R6RS module
> syntax in favor of “system” extensions [rant: the very idea of
> system extensions is anathema to Scheme and the Scheme Way]

I do not understand in what sense SRFI 9 is a system rather than
a user extension, given the pure R5RS reference implementation.

> What I do not understand is our refusal to use a syntax both
> successfully demonstrated as workable and successful in R6RS as well
> as fundamentally more scalable and open to clean extension. This
> makes no sense, given the trivially easy way in which this could
> have been addressed. The end result of this is that any real Scheme
> system worth its salt will included its own, proper record system,
> rather than extending the syntax of the standard one.

This claim seems to conflate the question of stronger record systems
(which you agree were out of scope for WG1) with the specific syntax
of define-record-type.  The latter was retained from SRFI 9 solely
for backward compatibility, simply because SRFI 9 is in fact so widely
implemented -- which is because it is so easily implemented either in
plain R5RS or on top of almost any existing record system, whether R6RS,
SRFI 99 procedural, or various implementations' own record systems.

In addition, SRFI 9 syntax is not totally inextensible, as the SRFI 99
syntactic module shows: I intend to propose at least (foo bar) as the
record type foo extending bar, and the use of #f to mean "no constructor",
as WG2 extensions.  Non-hygienic but convenient record-type defining
forms are also a possibility: if they are not upward compatible with
the standard syntax form, I don't think that matters so much, as long
as the records defined thereby are still compatible.

> The standard has, as a whole, favored the introduction of new procedure
> same thing. In some cases this makes a bit of sense, as it would be
> unwieldy to do otherwise. However, there are other places where this
> does not make sense, and in particular, places where parameters, which
> we provide, could more readily be used. These places include procedures
> that provide behavior which is inherently dangerous and ought not to
> receive a full procedure name. The write procedures come to mind. 

As you say, write-simple is inherently dangerous, but that's precisely
why it needs a name that is lexically apparent.  If the behavior of write
were controlled by a parameter with values 'simple, 'shared, and 'cyclic,
then the only safe way to call it would be immediately (lexically)
inside a parameterize syntax form:  (parameterize ((write-mode 'cyclic))
(write x)).  In any other case, you would take your chances with the
current setting of the parameter.  So given the above, what is more
natural than to wrap it in a procedure abstraction and give it a name?

> The include and include-ci forms also come to mind. 

Those are syntax.  Parameters are run-time objects and can't affect
syntax expansion without introducing low-level macros.

> There are places in the standard where we have fundamentally introduced
> gratuitous incompatibility with the R6RS standard “just because
> it’s R6RS.” An example is the error procedure. Here, there was
> no reason not to diverge from R6RS’ behavior, especially given that
> the R6RS behavior is a more expressive, useful form.

I assume you mean "no reason to diverge".

There was a straight choice of compatibility with the very widespread
SRFI 23 or compatibility with R6RS here.  The choice of the former is
an incompatibility, but hardly a gratuitous one.

> Now, I’d like to make a comment at this point. The WG1,
> by this standard, would seem to have no conception of user
> extensibility.

That is grossly exaggerated.  R5RS has the strongest system of procedural
and control abstraction of any programming language, and more syntax
abstraction facilities than almost any.

> The Scheme language itself is supposed
> to allow the user to extend the system in powerful ways, and Scheme
> has been moving in this direction more and more. Real Scheme systems
> exist that allow the user to create their own workable library systems
> extensions, or to really do conditional expand-time expansion without
> requiring system extensions for feature symbols. All of this can be
> done programmatically and using no more than the constructs provided
> by R6RS.

In powerful ways, yes, but not in every conceivable way.  In particular,
R6RS does not allow conflicting definitions of identifiers at different
phases, and explicitly forbids lexical extensions.  Racket, indeed,
provides these things, but only by bypassing R6RS altogether.

> We have made strange decisions that simply don’t make much
> sense. For example, the choice to remain to the single unspecified
> value instead of an unspecified number of values.

No R6RS system actually returns anything but a single value.

> Maybe one day the community will see what a good thing it was to have
> syntax-case in a standard. 

Dude, if you had voted for syntax-case, it would already be in the
R7RS-large pipeline, but you didn't.  As it is, I'm going to reinject
it in hopes that enough people will vote for it.

-- 
If I read "upcoming" in [the newspaper]              John Cowan
once more, I will be downcoming                      http://www.ccil.org/~cowan
and somebody will be outgoing.                       cowan@x

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports