On 12/15/05, Darren Duncan <[EMAIL PROTECTED]> wrote: > I propose, perhaps redundantly, that Perl 6 include a complete set of > native
Okay, I'm with you here. Just please stop saying "native" and "core". Everyone. <rant> Remember, syntax in Perl 6 can be stuffed in a library like anything else. You don't get much out of making it "truly core" (that is, in the language without any use statements) besides the fact that you tie yourself to all the idiosyncrasies of a single implementation instead of allowing multiple. Let's talk about what the module would look like, and then in a different discussion talk about which modules are used by default. </rant> > language constructs for a relational data model, akin to that > introduced in E. F. Codd's classic paper, "A Relational Model of Data > for Large Shared Data Banks" (a copy of which is at > http://www.acm.org/classics/nov95/toc.html ), and also discussed at > length in such books as C. J. Date's "Database in Depth" (O'Reilly, > 2005). Codd's paper itself (see 1.5) says that the necessary pieces > are good candidates for a sub-language of any typical programming > language. I would like to hear from Ovid and Dave Rolsky on this issue too, as they seem to have been researching pure relational models. > Essentially it comes down to better handling of data sets. Cool. I've recently been taken by list comprehensions, and I keep seeing "set comprehensions" in my math classes. Maybe we can steal some similar notation. > What I would like, for example, are standard data types which are > akin to Relations/RelVars/etc (tables/rowsets), Tuples (rows), > Attributes (fields), Sets (enums), Domains (data types) and such. > Largely these already map to existing Perl 6 entities: > > * a Domain is like a class that defines a set of possible values, > and each value can be multi-part; equal to a perl Class > > * an Attribute stores a value which is a perl Object > > * a Tuple is an associative array having one or more Attributes, and > each Attribute has a name or ordinal position and it is typed > according to a Domain; > this is like a restricted Hash in a way, where each key has a specific type Hmm. I would say it's a hash not so much. For instance, the difference between an array and a tuple in many languages is that an array is homogeneously-typed--that's what allows you to access it using runtime values (integers). Tuples are heterogeneously-typed, so you can't say my $idx = get_input(); say $tuple[$idx]; (Pretend that Perl 6 is some other language :-), because the compiler can't know what type it's going to say. In the same way, I see a hash as homogeneously-typed, because you can index it by strings. What you're referring to as a tuple here would be called a "record" or a "struct" in most languages. > * a Relation is an unordered set of Tuples, where every Tuple has > the same definition, as if the Relation were akin to a specific Perl > class and every Tuple in it were akin to a Perl object of that class When you say "unordered set" (redundantly, of course), can this set be infinite? That is, can I consider this relation (using made-up set comprehension notation): { ($x,$y) where $x & $y (in) Int, $x <= $y } And do stuff with it? > Specifically what I would like to see added to Perl, if that doesn't > already exist, is a set of operators that work on Relations, like set > operations, such as these (these bulleted definitions from "Database > in Depth", 1.3.3, some context excluded): > > * Restrict - Returns a relation containing all tuples from a > specified relation that satisfy a specified condition. For example, > we might restrict relation EMP to just the tuples where the DNO value > is D2. Well, if we consider a relation to be a set, then we can use the set operations: my $newrel = $emp.grep: { .DNO === 'D2' }; I don't know what EMP, DNO, and D2 are... > * Project - Returns a relation containing all (sub)tuples that > remain in a specified relation after specified attributes have been > removed. For example, we might project relation EMP on just the ENO > and SALARY attributes. Hmm... Well, if we pretend that records and hashes are the same thing for the moment, then: my $newrel = $emp.map: { .:<ENO SALARY> }; (See the new S06 for a description of the .: syntax) > * Union - Returns a relation containing all tuples that appear in > either or both of two specified relations. Already have it: $rel1 (+) $rel2 > * Difference - Returns a relation containing all tuples that appear > in the first and not the second of two specified relations. Already have it: $rel1 (-) $rel2 > * Join - Returns a relation containing all possible tuples that are > a combination of two tuples, one from each of two specified > relations, such that the two tuples contributing to any given result > tuple have a common value for the common attributes of the two > relations (and that common value appears just once, not twice, in > that result tuple). NOTE, This kind of join was originally called > the natural join. Since natural join is far and away the most > important kind, however, it's become standard practice to take the > unqualified term join to mean the natural join specifically, and I'll > follow that practice in this book. I would totally tell you what the best way to do this was if I could understand what the hell it was talking about. Examples? Proposals? > * Divide - Takes two relations, one binary and one unary, and > returns a relation consisting of all values of one attribute of the > binary relation that match (in the other attribute) all values in the > unary relation. Again, I don't follow. Luke
