[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Procedures (interfaces)

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.  


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