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: >> 1. The SRFI process is not for preliminary ideas. If there are several >> major issues to resolve, you're *supposed* to withdraw the proposal >> until you've worked them out. scgmille@xxxxxxxxxxxxxxxxxx wrote: > Round and round we go. I don't characterize the remaining issues as > major. If releasing the implementation without them would create a defect, they're major issues. And some of the remaining issues would create defects. Therefore, they're major issues. Also, the SRFI process doesn't even require major issues: active discussion and revisions alone are sufficient to reject a proposal, because they're evidence of immaturity. >> 2. Withdrawal is not supposed to delay anything by a year. You can >> potentially resubmit in 30 days and finalize 60 days after that -- IF >> you resolve all of the issues that led to withdrawal in the first >> place. > Sorry, I was basing that off the flawed 6 month draft period. > Nevertheless, it would delay concrete collections for two draft > periods + 30 days, assuming the second draft didn't run into a > similarly vehement opposition. Why not submit the naming standard and the concrete collections simultaneously, then? Personally, I think it would be better to just propose the concrete collection SRFI and let it create a de facto standard for naming. Have you ever heard of a naming standard that succeeded without a concrete implementation to "sell" it? > I see it as a tremendous loss to withdraw an SRFI which is largely > complete and of such utility to the Scheme community. Without a concrete implementation, it isn't "largely complete," and you're *vastly* overstating the value of naming conventions per se. >> 3. The desire to get a SRFI finalized and to build on it is *not* a >> good excuse to rush into finalizing an immature proposal. > I agree with everything here except for the immaturity assertion which > time and time I've said is your subjective opinion. That's because, once again, you're ignoring the evidence and the objective standards used to define it. SRFI-44 is immature according to SRFI process guidelines. It's immature according to any reasonable standard. Is it stable? No, it's been revised recently. Are all major issues resolved? No, there are still some potential defects. Has it seen extensive use in a production environment? No. You keep claiming that it's mature because it's based on other collection libraries. While the concept of collections may be mature, the SRFI-44 implementation of them is not. (Assuming that you're even willing to call it an implementation. I'm not.) >>> SRFI-34 didn't provide a complete package. >> How so? It's entirely usable on its own. It provides everything that >> primitive C++ exceptions give you, for example. > As is SRFI-44. The Scheme collections provided are entirely usable on > their own. What features does SRFI-44 add that we don't already have? A standard naming convention? That's not compelling. Enumerators? They already exist as part of SRFI-1 and SRFI-13. Some vaguely-specified polymorphism? The cost isn't worth the benefit. SRFI-44 does not have sufficient features to stand on its own as an implementation. It's a coding standard. > Nor will future collections be necessary for SRFI-44 to be useful. You're joking, right? I'd much rather use SRFI-1 and actually get a rich set of features for dealing with lists than use SRFI-44 to get a small handful of primitives that I could write myself more quickly than I could figure out how SRFI-44 works. > To be sure, thats not largely the point of the SRFI, but I don't > believe that conflicts with the spirit of the process, to advance > portable features beyond what is in R5RS. Where are the advancements? Quit pretending that it's more than a coding standard and a vague specification of polymorphism. As Tom pointed out, the polymorphism part is actually *disadvantage* for implementors, because it's underspecified and difficult to implement. -- Bradd W. Szonye http://www.szonye.com/bradd