First of all, Sam Vilain, thank you for your responses.
Giving these issues more thought, I'm am now leaning towards the idea
that the best way to provide relational algebra in Perl 6 is that the
relation-land Tuple and Relation each be a Role which various other
classes can provide to their users.
For one thing, this lets people use more types of data collections in
the forms where they currently sit, rather than requiring them to
first convert the data into separate Tuple or Relation objects, in
order to apply relational algebra to them. And I suppose that's "the
Perl way". Having things just work the way people intuit that they
ought to, given conceptually similar examples.
Moreover, some implementations of the Tuple and Relation roles can go
beyond the basics and provide features often associated with those
roles but that aren't part of the core algebra (such as various kinds
of type based or whole-set constraints, or various tied means of
persistence), while other implementations of those roles don't have
to.
Moreover, one key distinction that some implementations can have from
others is to whether they are mutable. Some implementations could be
mutable and others not. All of the generic relational algebra
operators are not mutators, so they will work equally well with
immutable or mutable implementations. That said, for this to work
properly in all cases, Perl 6 will need to provide a way (and it
probably does) for a routine to examine the signature of an anonymous
routine passed in as an argument, and make sure that its parameters
are all read-only; some generic relational operators, such as
restrict() and extend(), would take routines as arguments, like
grep() and map() do, and we don't want them to try mutating their
arguments.
As an aside, you'll recall that I said any other type could be
implemented over relations, such as sets or arrays etc. However,
every attribute ("column") of a relation has a name, but things like
sets or arrays conceptually don't need them and so having sets or
arrays or hashes etc implement the Relation role could be difficult,
one might think. But I say there is no problem here. We can simply
reuse the names of "methods" we already have on those types. For
example, a Hash object seen through a Relation role would have 2
attributes named "keys" and "values". With sets, its just "members"
or "values" or whatever. Though I suppose the names may need more
creativity with a shaped hash or array, where each dimension should
be referrable to by a distinct name (a dimension index number if
necessary), unless we cop out and make "keys" for a shaped hash or
array to be of type Seq, where the one value encompasses all
dimensions; such an approach is perfectly valid for a Relation role,
but it may or may not be less useful in practice.
Getting back to the main topic, if we want to implement the Tuple or
Relation role in a way that each attribute ("column") of such is
specifically typed (because that tends to be the most common or
useful practice), it probably would work best to employ a class
factory (implementing said roles) where each distinct heading of a
Tuple or Relation corresponds to a distinct actual class definition,
where the relation-land attributes correspond 1:1 with actual class
attributes, and all the features for addressing, manipulating, and
defining said attributes with types can be reused. In this
situation, nearly every generic relational algebra operator would
necessarily be a factory for new classes; and there needs to be a way
to examine existing classes in enough detail to know what attributes
they have and/or clone parts of them into new ones (as I assume
Perl's various .meta provide). This approach is probably the most
powerful of all as an implementation.
This email is by no means exhaustive, but feedback is appreciated.
And keep in mind that the most important thing I'm suggesting here is
both that Tuple and Relation are roles, and that as many built-ins as
reasonable "do" (appropriately restricted versions of) them; if
people have disagreements, its mainly with that sub-suggestion that I
want to know about them.
Thank you. -- Darren Duncan
