Re: more closed-world chatter
Date: 6 May 2007 19:52:46 -0700
Message-ID: <1178506366.608434.111040_at_l77g2000hsb.googlegroups.com>
On May 5, 3:16 am, Marshall <marshall.spi..._at_gmail.com> wrote:
[snip]
> Lately I have begun to adopt a more set-theoretic,
> less type-theoretic view. In this view, the *type*
> of a relation (or the header, if you prefer) is simply
> the set of attribute names, and nothing else. There
> is a separate construct, the constraints, and join
> has to consider how to combine not only the attributes
> and the values, but also the constraints.
Consider these two types
In that case, the type of a relation could reasonably specify a domain
type like int for the type of a given attribute. By contrast a
relvar constraint to further constrain an attribute (ie beyond its
To the extent that this approach makes the system more weakly typed, we expect the compiler to be more accommodating. However in principle, in a given scenario a clever compiler could sometimes prove that a run time constraint will always be broken (in which case it produces a compile time error), or sometimes prove the constraint will never be broken (in which case it avoids the need for redundant and expensive run time checks).
Consider what happens as we move from weaker typing through to very strong typing: Performance reaches a peak somewhere in the middle. All things being equal, I personally prefer a language where its type system matches this sweet spot, and I can separately define stronger run time constraints in a declarative manner.
[snip]
> def pricedomain = set {1, 2};
> def anotherdomain = set {3};
>
> def R1 = set(price) [price : pricedomain] {(1)};
> def R2 = set(price) [price : anotherdomain] {(3)};
>
> def R = R1 & R2;
If this were static typed, we would expect to see type specifiers on R1, R2, R, rather than only in the value specifiers. Obviously that would be very painful. Any thoughts? Received on Mon May 07 2007 - 04:52:46 CEST