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 wrote: >> The SRFI specifies a type which is a bag but which is not a >> sequence. However, there is no implementation of that type. scgmille@xxxxxxxxxxxxxxxxxx wrote: > Thank you, that makes much more sense than what you had said before. > I challenge you once again to come up with examples of how the bag > interface is unimplementable. Once again, that's not how review works. You're supposed to defend your design by actually implementing it. It's one of the most basic requirements of the SRFI process and of software reviews in general. > The reference implementation implements more than one sequence, which > have bag semantics as well, so code coverage is obviously fine. But the interface itself is untested. Specifically, you haven't verified that the interfaces are correctly factored between bags and their subtypes. I spotted a defect in that area earlier; I don't remember whether you actually addressed it. This is why it's so important to *at least* actually implement everything. >> Drama has nothing to do with it. I'm going by objective standards for >> code reviews. "Major issue" means that it becomes a defect if you >> don't fix it before release. > What makes you think it won't be fixed before release? Where did I say that it wouldn't be? My point is that the SRFI is not mature. Not according to the guidelines of the SRFI process or any other reasonable measure I can think of. > Nevertheless, this SRFI has really only seen around 90 days of > discussion .... And that's already too much, especially with active discussion and revision still going on. Those guidelines exist for a reason, to discourage people from releasing immature, untested implementations. > Though I am not the authority, I would like to again say that the SRFI > process is a guideline whose rules are in place to prevent specific > abuses such as SRFIs of indefinite extent. The process doc and FAQ are quite clear: The guidelines are in place to prevent finalization of an immature SRFI, and SRFI-44 meets all of the guidelines for an immature SRFI. >> Why would you be disappointed, when that's the documented rule? > Because it would extend for a year the amount of time Scheme goes > without a coherent collections API. And why is that important (other than the fact that you have a lot invested in it)? What good is the API without the collections themselves? Naming standards are important, but you're seriously overestimating their importance. Also, you're being too optimistic about the acceptance of this SRFI, methinks -- abstract APIs without concrete implementations have a very, very long history of failure. You're probably better off skipping straight to the concrete collections SRFI and hoping that its conventions catch on as a de facto standard. Otherwise, you're far too likely to run into a combination of unexpected defects (because the interface is untested) and Not Invented Here (because implementors have very little reason to follow somebody else's naming conventions unless you give them something of value besides just a list of names). -- Bradd W. Szonye http://www.szonye.com/bradd