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