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:
>> Also, my issues include SRFI-44's failure to meet the basic
>> requirements of a SRFI. The late date has very little to do with
>> that. The original proposal did not address compatibility issues, and
>> because of that, SRFI-44 was nearly finalized with an undocumented
>> incompatibility with R5R6 Scheme. It took a risk (by not documenting
>> compatibility issues) that would have become a major defect had a
>> reviewer not caught it.
Taylor Campbell wrote:
> There _is_no_incompatibility_. R5RS _does_not_specify_ what
> {VECTOR,STRING}-SET! return; SRFI 44 does. That is an _extension_
> that is _compatible_.
Will you two please set your egos aside and examine facts instead of
making excuses? According to the original spec, SRFI-44 vector-set! was
not an extension. It was a linear-update function, which means that
users must rely on the return value and must not rely on side-effects to
the input vector. With the R5RS version, users must rely on the
side-effects and must not rely on the return value. The two are purely
incompatible, and yet the author claimed he was ready to finalize the
SRFI.
> Before you start waving your hands (as if there hasn't been enough of
> that on every side of this flame war) about module systems such as
> PLT's where SRFI 44 as a module might prove to be problematic, I shall
> again state that this is _not_ meant to be a library SRFI.
That part of the argument is gravy. The incompatibility with R5RS is the
meat. But the gravy is important too: If the proposal is difficult or
expensive, it won't get implemented. If it creates outright
incompatibilities with R5RS, vendors won't pick it up -- it's irrelevant
whether it's a library or a core module.
Although seriously, you two are kidding yourselves if you really think
that a collections API is not a library module. And you're doubly
kidding yourselves if a collections API is a suitable vehicle for
implementing a change in the SRFI process.
> Library SRFI are 1, 13, 43, et cetera. This is a proposal for both a
> basic interface to various kinds of collections and a specification of
> some way to write generic operations on generic collection types.
And that's another problem with the SRFI. It's just an interface,
without a complete implementation. Reviewers (and not just me) are still
objecting that it's not obvious how to implement parts of the interface.
When I suggested just that earlier, Scott claimed that I was insulting
implementors everywhere by claiming that it wasn't clear enough!
>> Likewise, SRFI-44 takes risks by not fully implementing the
>> interfaces that it specifies. I'm not willing to accept that risk,
>> especially not after the compatibility problem.
> Despite the fact that there have been _plenty_ of other collections
> APIs from which this SRFI defines, and _plenty_ of implementations of
> them?
There have been *plenty* of other exception-handling systems in other
languages, but that didn't excuse SRFI-34 from providing a complete
implementation. You two need to demonstrate that *your* implementation
works.
> What more do you want the SRFI to meet?
Actually following the basic requirements of the SRFI process would
help.
> A concrete collections SRFI is a different beast.
And it would have a chance of actually being useful! Standardizing
interfaces is moderately useful, but it has little chance of succeeding
without concrete implementations and experience with it in real
projects. You've provided an "outline" implementation, which means that
it must meet a higher standard: The concrete implementation must be
obvious from the outline, and the rationale must be especially
compelling. Neither of those are true in this case.
--
Bradd W. Szonye
http://www.szonye.com/bradd