Re: Set-returning .keys (was Re: Smart Matching clarification)

2006-11-28 Thread TSa
HaloO, Darren Duncan wrote: This may be a non-issue from a user's viewpoint, but as a user, I want set operations that have sets as input to return sets as output by default. Eg, unioning 2 Set that have common values should return a Set. First of all the operations could be overloaded. Secon

Re: Set-returning .keys (was Re: Smart Matching clarification)

2006-11-27 Thread Darren Duncan
To start off with, I agree with your comment about making Set the main type and making Bag an extension built upon that, as complex is built upon num, etc. At 6:01 PM +0100 11/27/06, TSa wrote: And I still think that it is a good idea to name the set operations after their equivalent boolean c

Re: Set-returning .keys (was Re: Smart Matching clarification)

2006-11-27 Thread TSa
HaloO, Darren Duncan wrote: I was not meaning to get into implementation issues so much as just to say that all bag values are a superset of all set values. I agree with that. And I end up wanting a nice syntax to create a supertype. This is particularly needed if the Bag type shall be loadabl

Re: Set-returning .keys (was Re: Smart Matching clarification)

2006-11-27 Thread Darren Duncan
At 10:55 AM +0100 11/27/06, TSa wrote: Seq and Set are *both* more specific or restricted than Bag. So it would make more sense to say 'role Set does Bag' (and 'role Seq does Bag'), not 'role Bag does Set'. For illustrative purposes, replace "Set" with "Int" and "Bag" with "Num". Everything th

Re: Set-returning .keys (was Re: Smart Matching clarification)

2006-11-27 Thread TSa
HaloO, Darren Duncan wrote: To start off, I should clarify that I see little value for the existence of a Bag type except for certain matters of syntactic or semantic brevity, but that those alone can still warrant its existence. I partly agree. The Bag or MultiSet type naturally falls out as

Re: Set-returning .keys (was Re: Smart Matching clarification)

2006-11-24 Thread Darren Duncan
To start off, I should clarify that I see little value for the existence of a Bag type except for certain matters of syntactic or semantic brevity, but that those alone can still warrant its existence. A Bag is for marking when your duplicate-allowing collection is conceptually not ordered, a

Re: Set-returning .keys (was Re: Smart Matching clarification)

2006-11-24 Thread Darren Duncan
P.S. Sending this again, for timeliness, (first attempt was 20 hours ago) due to p6l mail server being down before. Sorry if you end up getting a duplicate later. To start off, I should clarify that I see little value for the existence of a Bag type except for certain matters

Re: Set-returning .keys (was Re: Smart Matching clarification)

2006-11-24 Thread TSa
HaloO, Jonathan Lang wrote: Other cases: What would 'Set.push(items)' and 'Set.pop()' do? What _is_ the appropriate way to go about adding items to (or removing items from) a Set, or of searching the Set for an element? Since Sets are immutable values there should be no push and pop methods.

Re: Set-returning .keys (was Re: Smart Matching clarification)

2006-11-23 Thread TSa
HaloO, Adriano Rodrigues wrote: And we may argue as well that being Bag a multiset, the set is a special case where all the elements have the same multiplicity. Yes, that would be a subset type. The thing I had in mind was 'role Seq does Bag' and 'role Bag does Set'. And classes with the same

Re: Set-returning .keys (was Re: Smart Matching clarification)

2006-11-23 Thread Adriano Rodrigues
On 11/23/06, TSa <[EMAIL PROTECTED]> wrote: HaloO, Darren Duncan wrote: > And if Seq and Set etc are interchangeable for all situations where it > doesn't matter whether the elements are ordered or not, then a lot of > times users won't have to care which they have. One can argue that we have t

Re: Set-returning .keys (was Re: Smart Matching clarification)

2006-11-23 Thread TSa
HaloO, Darren Duncan wrote: And if Seq and Set etc are interchangeable for all situations where it doesn't matter whether the elements are ordered or not, then a lot of times users won't have to care which they have. One can argue that we have the subtyping chain Seq <: Bag <: Set for these i