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.
With all due respect, this late in the SRFI's stage (nearly three months overdue for the allowed draft period), we can't really be making such drastic changes. The vast bulk of the SRFI was agreed upon through long discussions both on this list and in issue related discussions on the #scheme irc channel (for which logs are available). Your proposal makes several changes against the grain of goals raised by other (now lurking) list posters. First, the linear-update/purely mutable distinction is absent. Secondly, you allow for collections to behave as more than one type at once. This isn't forbidden in the current wording, but probably should be. This might be a useful extension, but it complicates implementation as it blurs type distinctions, and has similar effects on semantics (which you try and reconcile in your succeeding posts). I see your concerns related to R5RS compatibility, but your solutions again conflict with the goals of supporting functional, linear-update, and purely mutable datastructures. The procedures which arise out of SRFI-44 aren't meant to describe behavior in R5RS, but to show how R5RS datastructures would behave in the context of SRFI-44. In fact, implementations may choose not to implement the concrete collections defined by the SRFI (i.e. not implement SRFI-44). The primary goal is to provide a framework for future datastructures. Its still worthwhile to correct major problems with the SRFI at this stage (such as the problems with dictionary equivalence). But stylistic changes of this magnitude mean that undiscovered issues in a new design may go unnoticed if we finalize too soon. Scott On Tue, Oct 21, 2003 at 12:20:47AM -0700, Bradd W. Szonye wrote: > As promised, here is my suggestion for revising the collection > procedures. I tried to remain faithful to the original, and I tried to > avoid even minor changes. No, really! Nevertheless, I'm sure that it > will look like a big change. Therefore, let me preface my revision with > some rationales. Feel free to question or reject them -- as you've > already seen, I'm amenable to leaving things the way they are if you > have a good reason to do so.
Attachment:
pgptj8Rde0ctK.pgp
Description: PGP signature