Fundamental design flaws Tom Lord (29 Oct 2003 17:46 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (29 Oct 2003 19:13 UTC)
Re: Fundamental design flaws Bradd W. Szonye (29 Oct 2003 20:06 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (29 Oct 2003 20:47 UTC)
Re: Fundamental design flaws Tom Lord (29 Oct 2003 23:24 UTC)
Re: Fundamental design flaws Taylor Campbell (30 Oct 2003 01:53 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 04:42 UTC)
Re: Fundamental design flaws Tom Lord (30 Oct 2003 16:52 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 17:11 UTC)
Re: Fundamental design flaws Tom Lord (30 Oct 2003 16:33 UTC)
RE: Fundamental design flaws Anton van Straaten (30 Oct 2003 16:52 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 17:19 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 18:13 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 21:18 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 21:26 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 21:35 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 21:49 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 21:55 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 22:05 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 22:28 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 22:52 UTC)
Re: Fundamental design flaws Alex Shinn (31 Oct 2003 03:04 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (31 Oct 2003 03:20 UTC)
Re: Fundamental design flaws Alex Shinn (31 Oct 2003 07:13 UTC)
RE: Fundamental design flaws Anton van Straaten (30 Oct 2003 23:07 UTC)
Re: Fundamental design flaws Bradd W. Szonye (31 Oct 2003 03:12 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 21:57 UTC)
Re: Fundamental design flaws Tom Lord (30 Oct 2003 20:23 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 20:35 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 17:06 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 17:26 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 18:15 UTC)
Re: Fundamental design flaws bear (30 Oct 2003 18:48 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 19:35 UTC)
Re: Fundamental design flaws bear (30 Oct 2003 19:45 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 20:08 UTC)
Re: Fundamental design flaws bear (30 Oct 2003 20:40 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 20:48 UTC)
Re: Fundamental design flaws Tom Lord (30 Oct 2003 20:49 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 21:02 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 21:26 UTC)

Re: Fundamental design flaws Bradd W. Szonye 29 Oct 2003 20:06 UTC

On Wed, Oct 29, 2003 at 01:13:36PM -0600, xxxxxx@freenetproject.org wrote:
> Tom Lord wrote:
>> By the way, am I reading the reference implementation correctly to
>> conclude that:
>>
>> 	(define x (list 1 2 3)
>> 	(collection->list x)
>>         => (1 2 3)
>> but
>> 	(define x (list =? '(a . b) '(c . d)))
>> 	(collection->list x)
>>         => ((a . b) (c . d))
>>
>> So, for lists, the behavior of COLLECTION->LIST changes depending on
>> the types of values stored in the list?
>
> No.  The first list contains the values 1, 2, and 3, and the second
> contains the values (a . b) and (c . d).  I don't see what the problem
> is.

No, the second list contains the values =?, (a . b), and (c . d). One
procedure and two pairs. However, because the second list happens to
match the implementation of a SRFI-44 alist, the generic collection
function thinks it is one.

Depending on what you're trying to do, that's either a feature or a
major flaw. Fans of prototype-based OO may like the fact that the system
correctly detects "value-based" subtypes like this. People who really
want a (proc, pair, pair) tuple will probably be surprised, though.
--
Bradd W. Szonye
http://www.szonye.com/bradd