On 12/16/05, Ovid <[EMAIL PROTECTED]> wrote:
> --- 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)
I'm going to interject here with the following:
* P6 has the capability to be optionally strongly-typed. This is
obvious from the type signatures, if nothing else.
* According to the latest metamodel, as I understand it from
Stevan, types are, essentially, classes. This implies that I can
create my own types that inherit from some base type.
Overriding the operators in a generic way so that you have to have an
exact type match before you compare values also, imho, shouldn't be
that hard. So, for the relational calculus, you can have very strong
typing.
> * The domain of acceptable values (potentially infinite)
> * Selectors to cast to and from the value
> * Operators and their behaviors
I would argue that you don't have selectors, by default. You should
have to explicitly add a selector. Otherwise, into C-land you will go,
my son!
> 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.
If you end up in the relational section, which will be invoked with a
module, then you are choosing to use the typing that is available
through that module. I don't think anyone has argued that the
relational model should be built into the core or should even be a
module included in the core.
In fact, I see at least three modules coming out of this -
Type::Create, Type::Strengthen, and Model::Relational. Of these, I
would think only the Type:: modules should even have a chance to be in
the core distro. Type::Create may be a consequence of the metamodel,
but I'll let Steve or Audrey field that one.
Rob
