[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fundamental design flaws

This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.

On Wed, Oct 29, 2003 at 01:13:36PM -0600, scgmille@xxxxxxxxxxxxxxxxxx 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