Reasons for withdrawal scgmille@xxxxxx (28 Oct 2003 20:35 UTC)
Re: Reasons for withdrawal Tom Lord (28 Oct 2003 21:24 UTC)
RE: Reasons for withdrawal Anton van Straaten (28 Oct 2003 22:05 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 22:36 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (28 Oct 2003 22:44 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 23:22 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 02:50 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 03:19 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 03:31 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 03:38 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 04:36 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 05:02 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 05:32 UTC)
Re: Reasons for withdrawal Taylor Campbell (28 Oct 2003 22:56 UTC)
Re: Reasons for withdrawal Taylor Campbell (28 Oct 2003 23:06 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 23:16 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (28 Oct 2003 23:28 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 23:42 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 00:13 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 01:00 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 01:41 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 03:03 UTC)
RE: Reasons for withdrawal Anton van Straaten (29 Oct 2003 05:31 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 05:54 UTC)
RE: Reasons for withdrawal Anton van Straaten (29 Oct 2003 06:40 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 06:44 UTC)
RE: Reasons for withdrawal Anton van Straaten (29 Oct 2003 07:31 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 07:34 UTC)
Re: Reasons for withdrawal Thien-Thi Nguyen (29 Oct 2003 14:08 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 21:28 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (28 Oct 2003 22:02 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 22:22 UTC)
Re: Reasons for withdrawal Jim White (28 Oct 2003 22:15 UTC)
Re: Reasons for withdrawal Shiro Kawai (29 Oct 2003 01:25 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 01:44 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 04:10 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 04:53 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 05:10 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 05:17 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 05:31 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 01:49 UTC)
API conflicts (Was: Re: Reasons for withdrawal) Shiro Kawai (29 Oct 2003 05:48 UTC)
Re: API conflicts Shiro Kawai (29 Oct 2003 06:03 UTC)
Re: API conflicts scgmille@xxxxxx (29 Oct 2003 17:40 UTC)
Re: API conflicts (Was: Re: Reasons for withdrawal) Bradd W. Szonye (29 Oct 2003 06:03 UTC)
Re: API conflicts (Was: Re: Reasons for withdrawal) scgmille@xxxxxx (29 Oct 2003 14:19 UTC)
Re: API conflicts Shiro Kawai (29 Oct 2003 22:25 UTC)
Re: API conflicts scgmille@xxxxxx (29 Oct 2003 22:41 UTC)
Re: API conflicts Taylor Campbell (29 Oct 2003 23:58 UTC)
Re: API conflicts (Was: Re: Reasons for withdrawal) Taylor Campbell (29 Oct 2003 21:40 UTC)
A possible solution? bear (29 Oct 2003 22:59 UTC)
RE: A possible solution? Anton van Straaten (30 Oct 2003 07:40 UTC)
Re: A possible solution? Bradd W. Szonye (30 Oct 2003 10:07 UTC)
RE: A possible solution? bear (30 Oct 2003 15:13 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 15:20 UTC)
Re: A possible solution? Bradd W. Szonye (30 Oct 2003 15:27 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 15:39 UTC)
Re: A possible solution? Bradd W. Szonye (30 Oct 2003 15:43 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 16:11 UTC)
Re: A possible solution? bear (30 Oct 2003 17:02 UTC)
Re: A possible solution? Tom Lord (30 Oct 2003 19:58 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 20:15 UTC)
Re: A possible solution? bear (30 Oct 2003 20:53 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 21:07 UTC)
Re: A possible solution? Taylor Campbell (30 Oct 2003 21:08 UTC)
Re: A possible solution? Bradd W. Szonye (30 Oct 2003 21:11 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 21:17 UTC)
Re: A possible solution? bear (30 Oct 2003 23:11 UTC)
Re: A possible solution? Alex Shinn (31 Oct 2003 03:03 UTC)
Re: API conflicts Shiro Kawai (29 Oct 2003 23:19 UTC)
Re: API conflicts scgmille@xxxxxx (30 Oct 2003 00:26 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 05:32 UTC)
Re: API conflicts bear (30 Oct 2003 06:22 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 06:23 UTC)
Re: API conflicts scgmille@xxxxxx (30 Oct 2003 13:54 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 14:01 UTC)
Re: API conflicts scgmille@xxxxxx (30 Oct 2003 14:16 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 14:29 UTC)
Re: API conflicts scgmille@xxxxxx (30 Oct 2003 14:58 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 15:22 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 01:50 UTC)
Re: Reasons for withdrawal Alex Shinn (29 Oct 2003 03:06 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 03:18 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 03:29 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 03:37 UTC)
Re: Reasons for withdrawal Alex Shinn (29 Oct 2003 06:16 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 14:25 UTC)
Re: Reasons for withdrawal Alex Shinn (30 Oct 2003 02:19 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (30 Oct 2003 04:42 UTC)
Re: Reasons for withdrawal Alex Shinn (30 Oct 2003 06:22 UTC)

Re: A possible solution? bear 30 Oct 2003 17:02 UTC


On Thu, 30 Oct 2003 xxxxxx@freenetproject.org wrote:

>On Thu, Oct 30, 2003 at 07:42:56AM -0800, Bradd W. Szonye wrote:

>> Why assume that it will become obsolete? If it does, a new SRFI can
>> specify how to upgrade. In the meantime, collection library implementors
>> have a portable extension mechanism that they can actually use.
>
>Because it will.  Scheme systems right now have dispatch mechanisms.
>Thats a fact.  It makes much more sense for this SRFI to integrate with
>those.  But we can't do that without a portable, pervasive dispatch
>system.  I suspect this will be standardized eventually, and when it
>does, collections should integrate with it.  Specifying a dispatch
>mechanism with this SRFI means that this SRFI has a limited lifetime
>before it has to be patched or abandonned.

   I met a traveller from an antique land,
   Who said -- "two vast and trunkless legs of stone
   Stand in the desert ... near them, on the sand,
   Half sunk a shattered visage lies, whose frown,
   And wrinkled lips, and sneer of cold command,
   Tell that its sculptor well those passions read
   Which yet survive, stamped on these lifeless things,
   The hand that mocked them, and the heart that fed;
   And on the pedestal these words appear:
   My name is Ozymandias, King of Kings,
   Look on my Works ye Mighty, and despair!
   Nothing beside remains. Round the decay
   Of that colossal Wreck, boundless and bare
   The lone and level sands stretch far away."
           -- Percy B. Shelley

It's a nice bit of poetry, isn't it?  The fact of the matter is
that everything becomes obsolete.  Ozymandias probably thought
he'd built something that would never become obsolete, but...
well.  Time marches on.

If I understand you correctly, what you are looking for is
mindshare.  You have an _Idea_, something you believe should
inform all future design, and you want to give it a _Realization_
that makes its usefulness apparent.

But Plato figured out thousands of years ago that purely Ideal
things cannot exist.  Nothing can exist without taking a concrete
form. The spirit, or Ideal Platonic thing, that refuses to take
on the limitations of a particular concrete embodiment cannot
come into the Real world.

But any particular Real thing is only an approximation of the
Ideal; there will always be unrealized potentials, because the
concrete embodiment chosen must be one thing, and not all the
other things it could have been.  Thus, things which are of the
real world, without exception, pass away.  Even scheme itself
is only one Realization of the Ideal of programming languages,
and will pass away or change beyond recognition in time.
Nothing that can exist in scheme can be immune to obsolescence.

Now, if you want your Idea to come into the real world, it has
to have a concrete form.  That concrete form will eventually
pass away.  But the Idea, if it is a good one, will be carried
forward, realized in other forms, adopted and reimplemented as
a design, and do what you want it to do - ie, inform all future
design.

Ozymandias, perhaps, is nearly forgotten, but the Ideal of
which he was a single incarnation has certainly found others;
empire builders and military dictatorships have been with us
forever; they are enduring ideas.

Now, I'm still convinced that this is a one-size-fits-none
proposal for making generic interfaces to things which are
different for good reasons. But if you have an Idea and you
want to give it a Realization that makes its usefulness
apparent, you have to Realize it in some particular form
which people can use.

Right now relying on dispatch mechanisms that don't exist
yet (or aren't universal and uniform yet) is not "a particular
form that people can use."  Relying on vectors is.

				Bear