Re: more closed-world chatter

From: David BL <davidbl_at_iinet.net.au>
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

    T1 = int
    T2 = { 1,5,17,22,105 }

I have the feeling it's not such a good idea to treat these in the same way. Otherwise what does it mean to distinguish between type and value? I would rather call T2 a value than a type, and keep the type system simple.

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 type) could be expressed using set/relation values like { 1,5,17,22,105 }. Most generally we expect such constraints to be enforced at run time, not compile time.

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

Original text of this message