Felix, please don't bother with Rapid. I have already a new syntax expander, which I am polishing in my free time when I don't write or review SRFIs, which is going to be a much better frontend. Am Di., 8. Sept. 2020 um 02:31 Uhr schrieb Felix Thibault <xxxxxx@gmail.com>: > > Ok, so after I finish with mit-scheme and rapid-scheme (the last two in the not working branch) and merge that, I was planning to do a rewrite [just to address the "the specification is not clear enough for implementers to use" issue, (and that may involve clarifying or/not/ellipsis patterns] using (at this point) srfi-1/srfi-115 as models. > > On Sat, Sep 5, 2020 at 3:36 PM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote: >> >> On Sat, Sep 5, 2020 at 12:27 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote: >> >>> >>> > If there are aspects of semantics that could be added/taken away to make the spec clearer, let me know. I have read that the srfi process has moved away from the idea of a "reference implementation" and can incorporate bug-fixes after finalization as long as the spec doesn't change. It may be that documentation of the use of pattern variables in predicates/fields belongs outside the srfi (although I think as long as it is a property of the implementation it should be documented somewhere). I have really only heard two opinions on this and I'm not sure if it's something no one uses or some people use or what. >> >> >>> Arthur can probably say much more about this. What the current vision >>> of SRFI 204 seems to be (if I have understood you correctly) is to >>> document the particular implementation by Alex and to provide a >>> centralized repository for the code. >> >> >> The specification in the document has always been what defines the SRFI. We moved from calling the implementation a "reference implementation" to a "sample implementation" because only the former has the connotation (or definition, in some circles) that it is what defines the semantics. >> >> Everything mentioned in the SRFI should be defined as clearly as possible in the SRFI. If a reader has to refer to the implementation for details, that's a bug in the document. The implementation should be viewed as a proof that it's possible to implement the specification, and perhaps that it's possible for it to be fast. Ideally, it's also portable, which means that Scheme implementers don't have to re-implement the spec from scratch. But even then it shouldn't be viewed as the actual specification. >> >>> >>> So far, I have understood that a SRFI should specify something that >>> Scheme implementations are encouraged to implement. For that, the >>> semantics of the specification should be clearly stated (and written >>> down independently of some particular implementation). The sample >>> implementation, on the other hand, demonstrates that the specification >>> is implementable. If in contradiction, the written specification >>> counts, not the sample implementation. >> >> >> Yes, exactly.
