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, Aug 7, 2013 at 8:50 PM, John Cowan <cowan@xxxxxxxxxxxxxxxx> 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