This page is part of the web mail archives of SRFI 110 from before July 7th, 2015. The new archives for SRFI 110 contain all messages, not just those from before July 7th, 2015.
On Wed, 7 Aug 2013 08:50:59 -0400, John Cowan <cowan@xxxxxxxxxxxxxxxx> 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