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: >>> The issue isn't whether its possible to connect a collection to some >>> dispatch system, but whether its possible to define an interface as >>> a frontend to any dispatch system. Its the latter that may not be >>> possible. > Bradd W. Szonye wrote: >> This is why experimentation and implementation experience are useful. >> It lets you know whether an abstract design is really workable, or if >> it's just another unimplementable abstract design. > This is why I didn't rule out the idea of a generic interface to > collection extension. It just doesn't belong in this SRFI. It seems to me (and to a few other reviewers) that you're building a house on a non-existent foundation. SRFI-44 is allegedly designed with extensibility in mind, but it doesn't actually specify how to extend it. Therefore, each implementor must come up with his own solution, which will become obsolete when (if?) somebody actually publishes the portable extension SRFI. You just objected to building obsolescence into SRFI-44, yet you have no problem with building obsolescence into the systems that implement it. I've seen a similar attitude on other issues. You don't want to constrain implementors, but by failing to specify key elements, you make life harder for them anyway. It'd be one thing if you based these decisions on experience (i.e., "I know that PLT and Scheme-48 handle this differently, so I have no choice but to leave the specifics undefined"). But that doesn't seem to be the case; instead, you seem to be guessing what will be "helpful" or "constraining." Now, potential implementors are trying to tell you, "HEY! Freedom is good, but it's not giving us freedom so much as it's making life difficult for us and our users." -- Bradd W. Szonye http://www.szonye.com/bradd