Set::Relation
---------------------------------------------------------------------------

Following is a summary of things that still need doing.

* Consider using Dist::Zilla for packaging.

* Add code examples, tutorial, cookbook, FAQ, etc.

* Make the test suite actually run all the code, not mostly just compile
it; maybe start off with running same code examples in docs, tutorial, etc.

* Consider adding support for unique key constraints, and not just
the introspection of existing candidate keys that the API has now.

* Consider adding public operators such as for comparing headings eg for
disjointness etc, mirroring some set operators, perhaps to help users
implement more operators?

* Consider adding disjoint insertion, union operators (same as normal but
fails on a duplicate).

* Consider exploiting the candidate keys feature to improve performance of
S::R objects by generally only comparing tuples for uniqueness on their
subtuples that range over a key's attributes.  Associated with this,
consider a more efficient variant of object internal indexes that are
simply a hash of tuples rather than a hash of singleton-set of tuples; the
normal index format generalizes for indexes on non-keys, and the variant
wouldn't.

* Consider support for S::R objects internally having symbolic
representations in terms of other objects or their internals, which is even
lazier than what we have now but requires more smarts.  For example, one
object is defined as another but for a tuple being inserted or deleted.  Or
perhaps more likely, Set::Relation will never do this in general but
Muldis::Rosetta would, probably as a side effect of its existing support
for functional Muldis D value expression code.

* On the other hand, a simple version involving making an internal relation
body optionally a 2-element array, one element pointing to the body of
another relation object, and the second element having new tuples that were
added (or a 3-element, where the third having tuples that were deleted),
S::R could realistically do that, so to make
union/diff/insertion/deletion/etc initially faster; the first element
would be undef if there is no other object being based on.  Hopefully
something like this will not make other parts of S::R too complicated.

* Consider adding a new class Set::Relation::V3 which is like ::V2 but
primarily that its tuples are internally represented by Perl Arrays rather
than Perl Hashes, and the relation heading is a Perl Array too, so each
attribute name exists just once, in the heading, not in each tuple, and
attribute values match with their names on common Array indices.  At the
very least this would make 'rename' very cheap initially (only the heading
is changed rather than every tuple), and also relation objects should
consume much less memory.  This would likely also more closely resemble how
non-trivial DBMSs tend to work internally since tuple storage as ordered
arrays rather than named arrays should be a lot more efficient and more
like how lower-level languages like C are accustomed to operate.  Or
perhaps more likely, Set::Relation will never do this but Muldis::Rosetta
would for its internal relation objects.

* Consider adding more mutator methods.

* Improve performance in other ways.

* Port this to Perl 6 again; meanwhile, a much older initial version
pre-dating this Perl 5 rewrite already exists FYI.

* Whatever else needs doing, such as, fixing bugs.