xxxxxx@freenetproject.org wrote:
> 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 ....

Understood.

> 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.

Are these goals archived anywhere besides the mailing list archive? Some
of my recommendations, like merging ! and !!, were already suggested in
the list. Others weren't covered at all.

> First, the linear-update/purely mutable distinction is absent.

I figured that you could add [!] after each ! if you decided to keep the
separate interfaces.

Then again, I'm the second person to suggest that it should be absent. I
agree that the pure-mutable concept is important. However, I'm not fond
of the way it appears in the procedural interface, and I'm especially
unhappy about the incompatibility it creates with R5RS (see below).

One of the reasons I don't like pure-mutable as implemented is that
you've provided pure-mutable versions of the mutators but not the
accessors. In fact, there's no provision for pure-mutable accessors at
all. While they may seem counterintuitive, they're a fundamental part of
some data structures (e.g., splay trees). As written, there's no way to
implement a splay tree at all: No mutable accessors and no accessors
that return the updated collection.

Oh, and one minor issue: The SRFI frequently drops the "pure" and simply
calls them "mutable" collections, which suggests that they're the
opposite of "immutable" collections, but they aren't. It even does this
in the interface, which is likely to cause confusion in code reviews.

> 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 would strongly object to any proposal that explicitly forbids
"multiple inheritance" of collections. More importantly, those
complications exist with or without "two-headed" collections. That's one
of the reasons dictionaries have so many conceptual problems.

> 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.

I see it the other way around: The SRFI includes interfaces which
introduce silent changes to R5RS semantics. If a developer ports
existing vector code to SRFI-44, he must change every use of vector-set!
in the application. Worse, the program will subtly fail if he misses any
changes, because the SRFI-44 has the same syntax but different
semantics. And just to add insult to injury, he must change his code
from impure to pure-functional style, since SRFI-44 does not define
vector-set!!.

Even in new code, what are the chances that a developer will forget to
use SRFI-44 vector-set! and try to use it with R5RS semantics instead?
This is a very likely source of errors. There's a similar problem with
string=, which is verly likely to get mixed up with string=?. These
silent changes and similar identifiers will also cause problems in code
reviews.

I would recommend against any serious use of SRFI-44 with these
problems. Errors are too likely to occur during programming and too
difficult to detect in reviews.

> 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.

I agree.

I'm truly sorry to say this, but given the late date and the issues
remaining, I would currently recommend that you withdraw the SRFI,
resolve the issues, and reopen the SRFI when it's ready. Regardless of
what you choose to do, my offer to help still stands. I do like the
SRFI, and I'm happy to help out with reviews, editing, implementation,
etc., but I cannot support it in its current condition.
--
Bradd W. Szonye
http://www.szonye.com/bradd