[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 Thu, Oct 30, 2003 at 12:40:17PM -0800, bear wrote:
> 
> 
> On Thu, 30 Oct 2003 scgmille@xxxxxxxxxxxxxxxxxx wrote:
> 
> >On Thu, Oct 30, 2003 at 11:45:26AM -0800, bear wrote:
> 
> >> On Thu, 30 Oct 2003 scgmille@xxxxxxxxxxxxxxxxxx wrote:
> 
> >> >But they cannot be defined if they don't apply to the general class of
> >> >collections.  They need to be defined for those concrete classes or a
> >> >more specific general one (like ordered tree).
> >>
> >> Of course they can be defined for generic collections.  You can get
> >> the last element of a list; it's just the worst possible structure
> >> for that operation to be efficient.  Similarly, you can get a range
> >> of keys from an unordered alist, or any of the other "shortcut"
> >> operations.
> >
> >But what about a dictionary with no ordering at all?
> 
> In that case you just get whichever N elements are most efficient
> to get.  Or maybe you call the error continuation and make the
> user replace them with a call that makes it *explicit* that he's
> not interested in orderedness anymore -- but that's self-evident
> if he's using an unordered collection type, so it seems needlessly
> pedantic to me.

Why?  You've defined a function called get-n-from-range or what have 
you, and it does nothing of the sort.  Its even worse for other 
functions where you can't just hand out n values from anywhere.  
This is the *fundamental* flaw with having a kitchen sink of operators 
which are efficient for collections you're thinking of.

	Scott

Attachment: pgp997mmBjgw9.pgp
Description: PGP signature