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

Reply via email to