Email list hosting service & mailing list manager


Re: Change: MUST support block comment "#|...|#" and datum comment "#; datum" David A. Wheeler 07 Aug 2013 23:56 UTC

On Wed, 7 Aug 2013 08:50:59 -0400, John Cowan <xxxxxx@mercury.ccil.org> wrote:
> ... 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.

Done.  It's gone entirely from the spec.

> 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.

Okay, I'll do that, and the "two levels" approach makes more sense to me.

For the "two levels", I think we should define a new term,
"native implementation", and then add a few additional requirements for
implementations that want to claim they are a "native implementation".
That creates a second level of conformance, without a lot of complication.

>  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.

Agreed. Done.

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

Whups.  Fixed.

--- David A. Wheeler