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.
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. cowan@xxxxxxxx --Isaac Asimov in Earth: Our Crowded Spaceship