On Wed, Oct 22, 2003 at 07:02:57PM -0700, Bradd W. Szonye wrote:
> > 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.

I'm not opposed to merging ! and !! in favor of the programmer checking
purely-mutable-collection? except on the grounds that it increases the
opportunity for error.  I'd like to hear another opinion (Matthias'
wasn't very strong either way, nor is mine).  I do like that it would
bridge some R5RS compliance issues.

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

Nothing prohibits them in a future SRFI.  But its quite unusual for
datastructures to require modification on access.  I never
encountered such a datastructure in the standard collection
libraries of any of the languages surveyed.  I'm not saying they don't
exist (obviously they do), but they're rare enough to merit special
treatment.

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

Fair point.

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

Yes and no.  Dictionaries have conceptual issues precisely because they
are a mapping where all other collection styles in the SRFI are just
collections.  This, more than any type hierarchy issue, is the reason
for dictionary weirdness.
Can you elaborate on the issues that exist outside of dictionaries?

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

Not pure-functional at all, but linear-updating.  This and decreasing
the number of procedures are as I see it the only decent rationale for
collapsing !! to !.

> 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.
This is more an issue for programmers than the specification of the
SRFI.  I frequently confuse remove from SRFI-1 and element remove, but I
don't blame Olin.

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

I can't speak for everyone here, but I don't think the flaws are as
grand as you think.  The SRFI is quite usable in its current form,
programmer confusion not withstanding.  The few exceptions are fixable,
and I intend to fix them.  I welcome your input.

	Scott