On Wed, Aug 7, 2013 at 8:50 PM, John Cowan <xxxxxx@mercury.ccil.org> wrote:
>
> 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 agree - the unsweetener doesn't really need to be so strictly specified.

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

I'm not sure it's such a big deal.  The intent is that
sweet-expression texts will have a #!sweet somewhere near the top (of
the file or the code section).  A "standard" REPL that doesn't support
sweet-expressions would misread the whole text anyway, so the extra
"#!sweet" isn't a big deal, it's just the first thing that indicates
what error happened.  On the other hand, a purely library
implementation will either provide its own REPL implementation (which
is basically just some variant of (define (sweet-repl) (print (eval
(sweet-read))) (sweet-repl)), with additional code to hack into the
underlying Scheme's module system or whatever things it needs to hack
into) - or it can't provide a REPL in the library, because the
underlying Scheme system doesn't provide programmatic access to the
things the REPL needs to do.

So I guess a two-layer conformance spec will do.

Sincerely,
AmkG