Re: Interface view of dictionaries
scgmille@xxxxxx
(26 Oct 2003 04:27 UTC)
|
Re: Interface view of dictionaries
Bradd W. Szonye
(26 Oct 2003 04:55 UTC)
|
Re: Interface view of dictionaries
scgmille@xxxxxx
(27 Oct 2003 19:21 UTC)
|
Re: Interface view of dictionaries
Bradd W. Szonye
(27 Oct 2003 22:54 UTC)
|
Re: Interface view of dictionaries
scgmille@xxxxxx
(27 Oct 2003 23:16 UTC)
|
Re: Interface view of dictionaries
Bradd W. Szonye
(27 Oct 2003 23:43 UTC)
|
Re: Interface view of dictionaries scgmille@xxxxxx (28 Oct 2003 00:05 UTC)
|
Re: Interface view of dictionaries
Bradd W. Szonye
(28 Oct 2003 00:10 UTC)
|
Re: Interface view of dictionaries
Tom Lord
(28 Oct 2003 01:40 UTC)
|
Re: Interface view of dictionaries
Bradd W. Szonye
(28 Oct 2003 04:29 UTC)
|
Re: Interface view of dictionaries
bear
(26 Oct 2003 07:47 UTC)
|
Re: Interface view of dictionaries
Bradd W. Szonye
(26 Oct 2003 08:56 UTC)
|
On Mon, Oct 27, 2003 at 03:42:55PM -0800, Bradd W. Szonye wrote: > Bradd wrote: > >> It should at least specify all important operations on the data types > >> it does describe. > > xxxxxx@freenetproject.org wrote: > > It does. Important operators are those that are needed to implement > > others. If it is impossible to implement an operator otherwise, then > > it may justify inclusion. > > It's *possible* to implement any operation using just a Turing machine > or pure lambda calculus. Anything more than that is just syntactic > sugar. Of course, syntactic sugar is necessary, so we define > "primitives" at a much higher level than a Turing machine. This is a fallacious argument. One cannot add operators atop the sequence interface, for example, if it did not have a sequence-ref or similar operator. Its these operators that are critically important. Of course I could implement a completely separate sequence API disregarding SRFI-44 using a turing complete language, but thats obviously irrelevant. > > You've defined a set of primitives that, according to Bear's experience > and mine, leaves some holes, especially performance holes. You may not > consider it important to include a primitive "find-and-delete-subsequence" > operation, but it's critical for some applications. > Then define it in another SRFI. That operation is far too specific to certain problem domains to include here. The rule of thumb is to not provide operators that cannot be implemented efficiently for the entire range of conceivable implementations of that collection type. > Worse, you don't even seem to find it important to listen to criticisms > of this nature. When I try, you accuse me of making dire warnings > without evidence. Just because you aren't listening to the evidence > doesn't mean that I haven't given it. You have made some dire warnings without evidence. You're assertion that bags may not be implementable was just such a statement. Other critiques you've raised have evidence, but I've argued that they just don't apply within the scope of SRFI-44. > > Maybe you're just frustrated by all the complaints so late in the draft > period, but you're only frustrating us too, by constantly insisting that > our issues are unimportant or by claiming that we don't provide enough > support for our complaints. I'm definitely frustrated that the SRFI had wide approval when it was only slightly delayed, and that these issues weren't raised during the draft period. I realize you were 'away from Scheme' at the time. But frustration continues to play no part in my arguments against many of your complaints. Scott