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

Re: Reasons for withdrawal

At Tue, 28 Oct 2003 21:37:26 -0600, scgmille@xxxxxxxxxxxxxxxxxx wrote:
> [1  <text/plain; us-ascii (quoted-printable)>]
> On Tue, Oct 28, 2003 at 07:42:20PM -0800, Tom Lord wrote:
> > 
> >     > From: scgmille@xxxxxxxxxxxxxxxxxx
> > 
> >     > There is simply no way to have genericly programmable
> >     > collections without some generic dispatch mechanism.  Nearly all
> >     > Scheme implementations currently have it.
> > 
> > So what if they do?  Are those mechanisms standardized in a SRFI?
> They don't need to be, just as the mechanisms for implementing 
> continuations or threads don't need to be standardized to support 
> SRFI-18.  It would be nice if they were, but we can have a portable 
> implementation without them.

The methods for implementing continuations don't need to be standardized
because they are already standardized and specified in R5RS.  Threads
have a standardization in SRFI-18 - if you were to write a future SRFI
that used multi-threading it would need to either depend on SRFI-18 or a
new threading SRFI, but it would be poor precedent to depend on library
X that implements co-routines for Scheme without first some agreement on
library X.  Otherwise the discussion for that SRFI in effect has to
validate not only the specific points of the SRFI but of the chosen
library as well.

Most Schemes have a dispatch mechanism, but they come in many flavors.
I suspect the TinyCLOS, StKLOS, SOS and Meroon families are close enough
to work together, but YASOS and the MzScheme object system are quite
different.  And even among the similar ones, there's no guarantee that
the "similar" systems won't encounter strange incompatibilities with
future sub-classing and extension of the hierarchy.  Saying "most
Schemes can do generic dispatch" is not a solid foundation.  Saying
"this SRFI uses TinyCLOS" requires standardization of TinyCLOS first.
And noone would take a cond-dispatch approach seriously since it is slow
and not forwards compatible.

You don't, however, need a full-blown, mother-of-all object systems for
this SRFI.  You just need single-dispatch for an single-inheritance
hierarchy, which could be done in a very simple SRFI.