This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
> Bradd W. Szonye wrote: >> 2. Implement them as an optional library. >> Disadvantages: This doesn't work well in PLT when the library makes >> changes to core-language interfaces. If you write a module in R5RS >> Scheme, you can't redefine the R5RS bindings. Unlike Scheme-48, the >> PLT module system does not permit shadowing (and for good reason, >> IMO). You can avoid this by implementing a SRFI as its own language, >> but then you run into the same problem when you try to combine two of >> them. scgmille@xxxxxxxxxxxxxxxxxx wrote: > Thats absolutely untrue. It is in fact a violation of R5RS to > prohibit overriding of the procedures and syntax from R5RS. You can override the procedures. However, it's very difficult to do it in a way that also allows modular programming. PLT Scheme obeys the overriding rules at top level but not within a module (which is fine, because the module feature is an extension with its own rules). Their rules for modules also make good engineering sense. However, it does not easily support things like modular *changes* to existing languages. That's not because it's a poor implementation, but because those changes are very difficult to design in a modular way. In other words, changes like SRFI-44's original vector-set! are difficult to implement in PLT because changes like that are poorly suited for modularity and reusability, not because PLT has a poor Scheme implementation. Also, those conflicts violate the requirements for releasing an SRFI, which "must list related standards and SRFIs, including dependencies, conflicts, and replacements." >> And I'll repeat what I said to Taylor: Until you've actually used >> this to create concrete collections, you're publishing a "Scheme >> Request for Design Docs," not a request for implementation. > Yes, the SRFI name itself is a bad match for what is occuring here, > but it is still the right venue. I disagree. Again, the SRFI Process Document states that all SRFIs "must contain a detailed specification. This should be detailed enough that a conforming implementation could be completely created from this description." As written, a Scheme implementation cannot completely create a set or a bag, because there is no concrete specification for a set or bag. I think it's very arrogant of you to insist that this is the right venue for your design doc, when the SRFI FAQ disagrees: Q: I really think that there should be a place to archive non-implementation documents. A: You're not alone! There seem to be lots of people who disagree with the editors on this point .... Q: Why do I have to include a reference implementation? A: See the discussion above about preliminary ideas. SRFIs are about implementation. If you haven't either: (a) built one, or (b) have a very clear outline of how to build one, then you aren't documenting anything useful about implementation. There is no clear outline on how to build a bag or set. There's no implementation of those collections at all. In an SRFI, you can't just wave your hands and insist that the implementation is obvious. Until you provide an actual implementation, there's no guarantee that your design doc is implementable at all. Yes, you've implemented parts of it, but large chunks are missing, and the SRFI itself is not sufficient to create an implementation. You could easily resolve this problem by actually specifying and implementing at least one collection of each type listed. Then it would be useful both as a SRFI and as a "meta-SRFI." But as written, it is not a SRFI, and it is not mature enough to inspire confidence in its use as a meta-SRFI. Note the last section of the SRFI Process Document: The editors may not reject a proposal because they disagree with the importance of the proposal, or because they think it is a wrong-headed approach to the problem. The editors may, however, reject a proposal because it does not meet the requirements listed here. In particular, lack of a reference implementation (as defined above) is grounds for rejection. This can only occur if the ``reference implementation'' requirement is being met by an outlined implementation (type 5), and there is consensus that the implementation outline is not adequate. Parts of this SRFI are implemented only in outline form, if even that. My opinion is that the outline is not adequate, because there's no proof of concept. Even if you don't want to specify a concrete bag and set in the SRFI itself, I insist that examples of use are necessary to demonstrate that the interface description is actually implementable. Note that this is never a permanent rejection, because creation of an implementation of one of the other types is a complete refutation of this basis for rejection. Again, I recommend that you set aside your personal desires and recognize that this SRFI is incomplete. -- Bradd W. Szonye http://www.szonye.com/bradd