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)
|
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