[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.

At Wed, 29 Oct 2003 08:25:39 -0600, scgmille@xxxxxxxxxxxxxxxxxx wrote:
> [1  <text/plain; us-ascii (quoted-printable)>]
> On Wed, Oct 29, 2003 at 03:12:27PM +0900, Alex Shinn wrote:
> > At Tue, 28 Oct 2003 21:37:26 -0600, scgmille@xxxxxxxxxxxxxxxxxx wrote:
> > 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.
> I know.  I note this in the Issues section, stating:
> "At the same time it is hoped that a future SRFI will specify a 
> mechanism which will allow a portable and efficient implementation of 
> collections to exist."
> I hope you'll agree that it is ultimately an implementation issue to get 
> the dispatch right, but its not that difficult since it is a very simple 
> form of dispatch.  Bugs will exist in implementations of anything, they 
> can be fixed.

True, it is very simple, which is why I think it would be better to
specify it clearly first.  If you break things into small pieces there's
less confusion (and less to argue about).

A Scheme that implements this SRFI would end up using either their
native object system, a portable object system like TinyCLOS, or a
miniature dispatch system like bear suggested.  I'm worried that these
are not semantically compatible.  In the absence of a dispatch SRFI I'd
like to see the exact semantics specified in detail in SRFI-44 to avoid
future problems (and if it truly is simple then this will be a short
addition).  Items that seem to need clarifying:

   1) single vs. multiple inheritance
       - just say single!
       - if multiple, what CPL do you use?
   2) single vs. multiple dispatch
       - multiple is probably needed for *-union, etc.
       - if multiple, how do you resolve conflicts?
   3) abstract vs. concrete
       - can concrete classes be sub-classed?
       - can new abstract classes be made?
       - can abstract classes sub-class concrete classes?

In the absence of these we don't have clear guidelines for extensions to
this SRFI, and future extensions are likely to have conflicts with each
other and/or specific implementations of the dispatch mechanism.