--- Rob Kinyon <[EMAIL PROTECTED]> wrote: > As for the syntactic sugar, I'm not quite sure what should be > done here. And, with macros, it's not clear that there needs > to be an authoritative answer. Personally, I'd simply overload > + for union, - for difference, * for cross-product, / for > divide, and so forth.
Bear with me for just a moment here while I provide some background. I'll eventually touch on Rob's topic. One of the issues with handling relations correctly in databases is the following: SELECT emp.name, cust.balance FROM emp, cust WHERE emp.id = cust.age That's perfectly valid SQL but it doesn't make a lick of sense. In the original relational model, that would not be a valid query because the emp.id would be a different type from the cust.age. Operations between different types are simply not allowed. However, sometimes it makes sense to allow those operations, though. For example, if cust.id and emp.id are different types but may share identical and meaningful integer values, you might want to compare those even though you can't. So every type must have "selectors" which behave more or less like we think of when we try to cast a variable to a different type. So what if, for some crazy reason, we really did want to compare emp.id to cust.age. If cust.age is an integer, we might have something like this pseudo-code: WHERE emp.id = EMP_ID(cust.age) And that makes it all valid. However, getting this far suggests an interesting question. What does the following mean? emp1.id + emp2.id That means absolutely nothing but that's OK in the relational model because it won't compile. Why? Because for any data type you wish to have, you must define the following: * The domain of acceptable values (potentially infinite) * Selectors to cast to and from the value * Operators and their behaviors In short, if you don't have a '+' operator defined for a given data type, you don't have to worry about non-sensical behaviors like the above. (Yahoo!'s spell checker tried to change that to "non-sensual behaviors". I have no further comment.) Needless to say, in order to properly apply the relational model, we wind up with mandatory strong typing and this takes us very far afield from Perl. If we skip the strong typing, we may still have something good, but it won't be the relational model. Of course, all of this would put us on the doorstep of logic programming but, if I recall correctly, a decision was already made that Perl 6 wouldn't be delayed for its inclusion. A sad, but necessary choice. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
