On Tue, 28 Oct 2003 xxxxxx@freenetproject.org wrote:

>> Well, gosh.  It doesn't seem to me like a minor point.   It doesn't
>> seem like a problem that is really fixed by a quick tweak.  It seems
>> to me to point to some deep conceptual errors in the whole framework
>> of 44.
>>
>Hmm?  I just pointed out how its very much by design to have those
>functions behave how they do.

And that's exactly the problem.  those functions behave the way they do
by design, and they behave wrong.

That means that it is the design, and not the functions, that is
wrong.  If it were the functions that were wrong, we would have "minor
issues" -- that is, everybody in agreement on what ought to be
provided and how it ought to behave, but just a few implementation
tweaks remaining to make it all work and provide something useful to
people who pick it up.

No programs have been written using the system of interfaces proposed
in this SRFI.  That's a major issue.

As it is, there isn't sufficient implementation to prove to anyone
that the design is okay.  SRFI's are an +implementation-based*
process, so that is a VERY major issue.  That is a major issue.

There is substantial disagreement about whether the design goals
stated are worthwhile design goals in the first place.  Claiming the
SRFI meets it's design goals when it's the goals themselves that are
being questioned is a nonsequitur.  My particular issue is that
efficiency and convenience do not seem to be among the design
goals. That's a major issue.

This SRFI depends on generic dispatch but no specific means of generic
dispatch has yet seen widespread agreement and providing for it is either
an efficiency hit on or changes the fundamental architecture of many
scheme systems.  That is a major issue.

The "implementation" provided with this SRFI adds no capabilities to
any scheme system that drops it in and uses it.  This provides no
compelling reason for any scheme implementor to support this SRFI
in his or her system. That sets this SRFI up to be widely ignored.
I would consider that a minor issue as regards this SRFI, but needless
damage to the community-based value of the SRFI process itself through
loss of respect.

This SRFI attempts to use the SRFI process to change the SRFI process
itself.  That risks further damage to the SRFI process, which is again
much more important than this SRFI.  That is a major issue.

Sigh.  I know I said I'd try to avoid contributing more heat to this
discussion, but you're specifically asking for people to explain to
you what the major issues are and I'm trying to shed light rather than
heat.

I was initially concerned about efficiency alone; I posted for
comparison the interface of the library I'd written to ask, "so how do
I achieve these efficiencies given the interface in SRFI-44?"  You
could not have picked a worse way to respond if you had tried,
especially winding up with the comment that SRFI-44 was virtually
identical to that library interface.  Your answer was so flippant and
so completely blind to the efficiencies I was asking about that I was
shocked, lost confidence in you as a coder or designer, and
scrutinized this SRFI with a *VERY* critical eye to see what else was
wrong (because with an attitude like that toward efficiency, there
were bound to be other things wrong).

I've done six years of software QA.  When you're working with datasets
of unrestricted size, differences of order in the efficiency of the
implementation of EVERY function really are a make-or-break concern.
You cannot standardize something that does not provide room for a
maximally-efficient implementation of every function.  Maybe you can
finalize the SRFI, but if you do, nobody will care.

				Bear