Re: using the newer collection types

[Darren Duncan]

At 10:51 AM +1200 5/5/06, Sam Vilain wrote:
 >Moreover, the Relation type has these
operators that the Set type doesn't have: rename(), project(),
restrict(), extend(), join(), divide(), summarize(), group(),
 >ungroup(), wrap(), unwrap(), matching(), etc.
Is there a reference for the meaning of these methods?

 >7.  Can we add some operators to Mapping that are like the Relation
ones, so that implementing a Relation over Mappings is easier (or,
see the end of #8)?  Eg, these would be useful: rename(), project(),
extend(), join().  In particular, implementing join() into Mapping
would help save CPU cycles:

Again, a reference to a prototype of the behaviour would be useful.

There are many written references to these methods; just type 
"relational algebra" into Google.

That said, some of those search results may not explain things in the 
same way, so I specifically prefer the definitions in Date and 
Darwen's book "Databases, Types, and The Relational Model"; 
equivalent definitions are probably on the 'net' but I'm not sure 
where.

I also defined part of the join() operator in my last email.  How 
that definition, for Tuples, extends to a Relation is that you pair 
every tuple in each relation being joined to every tuple in each of 
the others, and apply my earlier definition with each pairing; the 
output Relation contains a tuple where the earlier definition 
returned a tuple, and no tuple where it returned undef.

Alternately, if you want to wait a week, I will be coding up 
documented implementations as soon as possible within Pugs' 
ext/Relation/ dir.

But in order for me to do this, I was needing some answers about the 
nature of existing types like Set and Mapping and Junction etc, which 
I asked in this email.

Regarding your other comments:
I don't think this terminology or these restrictions are particularly
useful.

I do think that a Pair should be a sub-type of a more general "Tuple"
type, with the 'where' clause being { .items == 2 } or something like that.

I think that the most flexible arrangement is to define;

- a Collection as a Bag of Tuples
- a Relation as a Collection where the tuples have a shape and no
duplicate tuples are allowed (but Relation does not need to be a core type)

Then, Mappings, Sequences, etc, become sub-types of one of the above two
types. For instance, a sequence is a Collection of (Int, Any) where the
first Int is unique across the collection. Similarly a Mapping is a
Collection of (Any, Any) where Unique(0).

You may be on to something here, but I'll withold comments for now.

My main concerns with this whole Relation thing are that I want an 
efficient way in Perl 6 to represent what relation-land's concept of 
tuples and relations are, as well as an efficient implementations of 
relational algebra that are just as easy to use and fast in Perl 6 as 
are the language's other collection types such as Sets.

If Perl 6 is to be the choice language of the singularity, it needs 
to be easy and fast to do any common type of work with it, and 
relational algebra is an extremely common kind of work being done.

-- Darren Duncan