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)

Re: Interface view of dictionaries scgmille@xxxxxx 28 Oct 2003 00:04 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