Both the symmetric_difference and unique are symmetric on all their arguments. For two sets they are identical but for more than two sets beware: symmetric_difference returns true for elements that are in an odd number (1, 3, 5, ...) of sets, unique returns true for elements that are in one set.

Some examples of the various set differences below (the _ is just used to align the elements):

The compare method returns a string from the following list: "equal", "disjoint", "proper subset", "proper superset", "proper intersect", and in future (once I get around implementing it), "disjoint universes".

Boolean contexts

the size of the $set is tested, so empty sets test as false, and non-empty sets as true.

Iterating

while (defined(my $e = $s->each)) { ... }

This is more memory-friendly than

for my $e ($s->elements) { ... }

which would first construct the full list of elements and then walk through it: the $s->each handles one element at a time.

Analogously to using normal each(%hash) in scalar context, using $s->each has the following caveats:

The elements are returned in (apparently) random order. So don't expect any particular order.

When no more elements remain undef is returned. Since you may one day have elements named 0 don't test just like this

while (my $e = $s->each) { ... } # WRONG!

but instead like this

while (defined(my $e = $s->each)) { ... } # Right.

(An undef as a set element doesn't really work, you get "".)

There is one iterator per one set which is shared by many element-accessing interfaces-- using the following will reset the iterator: elements(), insert(), members(), size(), unique(). insert() causes the iterator of the set being inserted (not the set being the target of insertion) becoming reset. unique() causes the iterators of all the participant sets becoming reset. The iterator getting reset most probably causes an endless loop. So avoid doing that.

For delete() the story is a little bit more complex: it depends on what element you are deleting and on the version of Perl. On modern Perls you can safely delete the element you just deleted. But deleting random elements can affect the iterator, so beware.

Modifying the set during the iteration may cause elements to be missed or duplicated, or in the worst case, an endless loop; so don't do that, either.

Cartesian Product and Power Set

Cartesian product is a product of two or more sets. For two sets, it is the set consisting of ordered pairs of members from each set. For example for the sets

(a b)
(c d e)

The Cartesian product of the above is the set

([a, c] [a, d] [a, e] [b, c] [b, d] [b, e])

The [,] notation is for the ordered pairs, which sets are not. This means two things: firstly, that [e, b] is not in the above Cartesian product, and secondly, [b, b] is a possibility:

The $c and $d will be of the same class as $a. The members of $c and $c in the above will be anonymous arrays (array references), not sets, since sets wouldn't be able to represent the ordering or that a member can be present more than once. Also note that since the members of the input sets are unordered, the ordered pairs themselves are unlikely to be in any particular order.

If you don't want to construct the Cartesian product set, you can construct an iterator and call it while it returns more members:

The anonymous subroutine gets as its first (and only) argument the set to display as a string. For example to display the set $s as a-b-c-d-e instead of (a b c d e)

$s->as_string_callback(sub{join("-",sort $_[0]->elements)});

If called without an argument, the current callback is returned.

If called as a class method with undef as the only argument, the original callback (the one returning (a b c d e)) for all the sets is restored, or if called for a single set the callback is removed (and the callback for all the sets will be used).

CAVEATS

The first priority of Set::Scalar is to be a convenient interface to sets. While not designed to be slow or big, neither has it been designed to be fast or compact.

Using references (or objects) as set members has not been extensively tested. The desired semantics are not always clear: what should happen when the elements behind the references change? Especially unclear is what should happen when the objects start having their own stringification overloads.

SEE ALSO

Set::Bag for bags (multisets, counted sets), and Bit::Vector for fast set operations (you have to take care of the element name to bit number and back mappings yourself), or Set::Infinite for sets of intervals, and many more. CPAN is your friend.