Re: Reasons for withdrawal

[scgmille@xxxxxxxxxxxxxxxxxx]

On Tue, Oct 28, 2003 at 08:49:44PM -0800, bear wrote:
> 
> 
> On Tue, 28 Oct 2003 scgmille@xxxxxxxxxxxxxxxxxx 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.

How is that behavior wrong please?

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

You don't have to agree with the goals.  Public acceptance will 
determine that just fine.

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

It specifies no means of generic dispatch because none is standardized.  
This does not limit the SRFI because ultimately the implementors will 
pick a dispatch form whether there is a standardized one or not.  This 
is not a programmer facing issue, so its irrelevant.

> 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 is flat wrong.  It allows one to consistently interchange values 
between the standard Scheme types, and consistenly enumerate over them.  
The current Scheme standard specifies no way to enumerate over all the 
composite datastructures at the moment.  

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

The editor doesn't seem to think so.

> 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'm sorry I've let you down, but I don't believe I'm letting the Scheme 
community down.  You've certainly not raised any compelling flaws that 
prevent future efficiency.

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

How is it that you think the current operators are inefficient?  I agree 
that there aren't shortcut operators in the SRFI, but as I've already 
said, there's nothing preventing their definition in the future 
collections specifications where they actually make sense.

	Scott

Attachment: pgpaDf3CuzOot.pgp
Description: PGP signature