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.
scgmille@xxxxxxxxxxxxxxxxxx wrote: > With all due respect, this late in the SRFI's stage (nearly three > months overdue for the allowed draft period), we can't really be > making such drastic changes .... Understood. > The vast bulk of the SRFI was agreed upon through long discussions > both on this list and in issue related discussions on the #scheme irc > channel (for which logs are available). Your proposal makes several > changes against the grain of goals raised by other (now lurking) list > posters. Are these goals archived anywhere besides the mailing list archive? Some of my recommendations, like merging ! and !!, were already suggested in the list. Others weren't covered at all. > First, the linear-update/purely mutable distinction is absent. I figured that you could add [!] after each ! if you decided to keep the separate interfaces. Then again, I'm the second person to suggest that it should be absent. I agree that the pure-mutable concept is important. However, I'm not fond of the way it appears in the procedural interface, and I'm especially unhappy about the incompatibility it creates with R5RS (see below). One of the reasons I don't like pure-mutable as implemented is that you've provided pure-mutable versions of the mutators but not the accessors. In fact, there's no provision for pure-mutable accessors at all. While they may seem counterintuitive, they're a fundamental part of some data structures (e.g., splay trees). As written, there's no way to implement a splay tree at all: No mutable accessors and no accessors that return the updated collection. Oh, and one minor issue: The SRFI frequently drops the "pure" and simply calls them "mutable" collections, which suggests that they're the opposite of "immutable" collections, but they aren't. It even does this in the interface, which is likely to cause confusion in code reviews. > Secondly, you allow for collections to behave as more than one type at > once. This isn't forbidden in the current wording, but probably > should be. This might be a useful extension, but it complicates > implementation as it blurs type distinctions, and has similar effects > on semantics (which you try and reconcile in your succeeding posts). I would strongly object to any proposal that explicitly forbids "multiple inheritance" of collections. More importantly, those complications exist with or without "two-headed" collections. That's one of the reasons dictionaries have so many conceptual problems. > I see your concerns related to R5RS compatibility, but your solutions > again conflict with the goals of supporting functional, linear-update, > and purely mutable datastructures. I see it the other way around: The SRFI includes interfaces which introduce silent changes to R5RS semantics. If a developer ports existing vector code to SRFI-44, he must change every use of vector-set! in the application. Worse, the program will subtly fail if he misses any changes, because the SRFI-44 has the same syntax but different semantics. And just to add insult to injury, he must change his code from impure to pure-functional style, since SRFI-44 does not define vector-set!!. Even in new code, what are the chances that a developer will forget to use SRFI-44 vector-set! and try to use it with R5RS semantics instead? This is a very likely source of errors. There's a similar problem with string=, which is verly likely to get mixed up with string=?. These silent changes and similar identifiers will also cause problems in code reviews. I would recommend against any serious use of SRFI-44 with these problems. Errors are too likely to occur during programming and too difficult to detect in reviews. > Its still worthwhile to correct major problems with the SRFI at this > stage (such as the problems with dictionary equivalence). But > stylistic changes of this magnitude mean that undiscovered issues in a > new design may go unnoticed if we finalize too soon. I agree. I'm truly sorry to say this, but given the late date and the issues remaining, I would currently recommend that you withdraw the SRFI, resolve the issues, and reopen the SRFI when it's ready. Regardless of what you choose to do, my offer to help still stands. I do like the SRFI, and I'm happy to help out with reviews, editing, implementation, etc., but I cannot support it in its current condition. -- Bradd W. Szonye http://www.szonye.com/bradd