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
At 10:54 AM +0100 11/28/06, Ruud H.G. van Tol wrote:
> 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.
I don't think that will work out. Modification of a Set is more complex
than mod
Smylers schreef:
> Ruud H.G. van Tol:
>> Darren Duncan:
>>> TSa:
set operations ... make them Bag operations to start with.
>>>
>>> I agree with ... making Set the main type and making Bag an
>>> extension built upon that, as complex is built upon num, etc.
>>
>> I don't think that will work
Ruud H.G. van Tol writes:
> Darren Duncan schreef:
>
> > TSa:
>
> > > set operations ... make them Bag operations to start with.
>
> > I agree with ... making Set the main type and making Bag an
> > extension built upon that, as complex is built upon num, etc.
>
> I don't think that will work
Darren Duncan schreef:
> TSa:
>> And I still think that it is a good idea
>> to name the set operations after their equivalent boolean
>> connectives:
>>
>> (|) union
>> (&) intersection
>> (^) symmetric difference
>>
>> Well, and to make them Bag operations to start with.
> To start off wi
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
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
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
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
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
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
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.
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
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
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
At 3:24 AM -0800 11/18/06, Jonathan Lang wrote:
Jonathan Lang wrote:
Larry Wall wrote:
> it seems to me that .keys.sort is
> suboptimal if sort has to second-guess the ordering provided by the
underlying hash.
Not only is it suboptimal, it might not be possible. Sorting depends
on cmp ret
16 matches
Mail list logo
