[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reasons for withdrawal

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
Bradd W. Szonye