David A. Wheeler scripsit:

> I think it's a very reasonable thing to *do*; I'm not sure that we should
> *spec* it.

Agreed.  I had actually forgotten that the unsweetener is described in
the spec, and now I think it ought to be left out altogether.  Since it
can be written entirely in portable Scheme, there is no reason for "the
implementation" to provide it; a user who wants it can simply find it,
just like any other portable Scheme application.

I also have issues with some of the MUSTard in the "Other requirements"
section.  For conformance, implementations MUST support `#!sweet`
and sweet-expressions in `read` and at the REPL, and MAY support
`sweet-read`.  I think this is exactly backwards, as it prevents pure
library implementations from being conformant.  There is often no way
to change which reader the REPL uses short of patching and recompiling
the Scheme implementation, and people who want sweet-expressions at run
time ought to be able to have them.

Either we have two levels of conformance, one for implementations that
support sweet-expressions in the default reader and for ones that do
not (which would be my preference), or default reader support ought
to be demoted to SHOULD or even MAY.  Per contra, the procedural API
should be fully specified and made mandatory: that is,	`sweet-read`,
`neoteric-read`, `curly-write`, and `neoteric-write` (with their R7RS
variants).  Also, why would you allow implementations of the readers
not to have an optional port argument?	Allowing the user to pass the
port should be a MUST.

(Minor nit: you say implementations MUST provide the writers and then
in the very next sentence say "If provided".)

--
Babies are born as a result of the              John Cowan
mating between men and women, and most          http://www.ccil.org/~cowan
men and women enjoy mating.                     xxxxxx@ccil.org
    --Isaac Asimov in Earth: Our Crowded Spaceship