Re: Fundamental design flaws

[scgmille@xxxxxxxxxxxxxxxxxx]

On Thu, Oct 30, 2003 at 02:28:04PM -0800, Bradd W. Szonye wrote:
> > Bradd W. Szonye wrote:
> >> How do the generic procedures know whether '((a . 1) (b . 2)) is a
> >> list or an alist? If it's based on content, you have isomorphism
> >> issues to resolve. If you're now using something like a record type
> >> for alists, then you're not really handling primitive alists.
> 
> scgmille@xxxxxxxxxxxxxxxxxx wrote:
> > They never receive ((a . 1) (b . 2)).  They receive an alist-dict,
> > which has structure beyond the stored values which it can dispatch on
> > (Taylor can comment more).  We don't handle primitive alists.
> 
> You make a big deal about how important it is to provide generic
> procedures for collections, but you don't support a very common
> collection type? Code that uses alists must choose between a complete
> port or no support? Actually, I suppose that a genuine alist would look
> like a "list" to SRFI-44.

Please get out of your head the idea that the 'look' of a datastructure 
has anything to do with how its dispatched.  alists by themselves are 
not a collection.  A collection is a combination of a datastructure 
(representation, storage model, etc) and a set of operators.  Shiro and
others pointed out real problems with treating alists as dictionaries 
without modification.  Because those problems exist, we have 
alist-dicts, which are dictionaries in the SRFI-44 sense, which store 
the mappings in an alist (which itself may be wrapped in something else 
to store key and value equivalence functions and to facilitate typing).

> Could you please explain how this is consistent with your goals? While
> it may be a good idea not to support "primitive" Scheme collections, it
> doesn't seem compatible with your goals.

The inclusing of concrete collections is in there for prooff of concept.  
Its a minor subgoal of the SRFI, dwarfed by the naming, semantics and 
protocol goals.

> 
> So are primitive lists and vectors supposed to be real collections,
> implemented by all SRFI-44 providers? If not, then why are they in the
> SRFI? If so, then how do you deal with lists and vectors that aren't
> *just* lists and vectors? Does SRFI-44 really treat a Scheme alist as if
> it were just a simple list?

44 never just takes an existing vector or list and says "Hey, you're an 
SRFI-44 sequence".  Valid 44 collections must be created using the 
make-list and make-vector or list and vector constructors.  Any behavior 
with primitive Scheme types is undefined.

> It'd be better to use distinct, non-primitive types for *all* of them,
> rather than fooling around with primitive ADTs inconsistently. If you
> do, however, be careful to rename "list" and "vector," like you renamed
> "alist."

Its not really necessary with list and vector so much since the 
operators are all largely compatible with R5RS.  See also the discussion 
on c.l.s. about PLT, raise, and modules (which your already involved in, 
right?)

	Scott

Attachment: pgp5uMyERWUVt.pgp
Description: PGP signature