Re: Values have types ??

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Tue, 09 Sep 2003 16:14:29 -0700
Message-ID: <bjlmoc$khtj2$1@ID-152540.news.uni-berlin.de>

Alfredo Novoa wrote:
> Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<bjgnju$h2b9n$1_at_ID-152540.news.uni-berlin.de>...
>
>

>>No, actually {2} is the set with a single element 2.

>
>
> Then {2} is not a type in the D&D model.
>
> The MST of a value must be choosed among the defined types.
>

Well, since types for relations and tuples are and should be automatically defined, why not the type {2}.

>

>>is superfluous, actually D&D are totally inconsistent when they require 
>>that types have names ("types are named sets") since relation types and 
>>tuple types obviously don't have user-defined names

>
>
> Agreed, but both parts of the books are independent.
>
>

Still inconsistent, and since the automatically named (or even anonymous if you will) relation types are essential for the system to support relational algebra *conveniently*, then it is clear that the system should not require that all types have pre-defined or user-defined names.

I mean would you like to annotate every projection you ever take with a "defined" type name ? Don't think so.

Do you want the type system for the primitive values to be different from the type system for relations, arrays and other "complex" types ?

>>, and at best should 
>>be system generated as such, there's no reason for the system not to 
>>generate a name for the type {2}.

>
>
> Yes, but you have to define the type in some way.
>

Easy, for every value x there will be the type {x}

just the same as for every name "column_name" and type t there have to be types
TUPLE(Column_name:t) and RELATION(Column_name:t)

>

>>Imagine that a user defines 2 types (in Tutorial D clumsy syntax, if you 
>>don;t believe this syntax go to page 259):
>>	
>>	TYPE PRIME IS INTEGER WHERE IS_PRIME(INTEGER)
>>	TYPE EVEN IS INTEGER WHERE INTEGER%2 == 0

>
>
> I don't think it is acording to the syntax of page 261. The CONSTRAINT
> token is missing, and WHERE is not a boolean operator.
>
>

I literally copied it from page 259, by the way it makes sense: the POSREP is that of integer and WHERE specifies the constraints.

Otherwise if you look the online grammar it is obviously wrong:

user_scalar_type_def        = TYPE type_name
                               possrep_defs opt_type_constraint
                             ;

So I can't define that PRIME is subtype of INTEGER and I'd have to invent POSREP for all subtypes which is counterproductive, by default subtypes inherti POSREP of supertype.

>>Now what's the MST(2) ???

>
>
> The type hierarchy is illegal because it is not a lattice. See chapter
> 15.
>

Oh, really ... And who will decide that it is illegal ?

The system ? The user ?

Exactly how ?

>

>>So bottom line you have 2 options :
>>	- either the type system is inconsistent opening the possibility of 
>>runtime type errors

>
>
> IMO the correct option is a compile time error.
>
>

Your opinion is obviously wrong. You want the computer to know mathematics, but the computer is as dumb as it gets.

There is no algorithm that the system should be able to run and decide that your type system is not a lattice. Because the type system relies on user specified constraints on user specified algebras, where specified is like using a Turing equivalent language, the system will not be able to tell even if IS_PRIME(x) always terminates.

The question that you have to answer yet, is what *value* does a type system like this provide ?

So there's no correct and wrong, there's useful and useless. For example it is incorrect that SQL is a wrong model of reality (mathematical reality) and relational model is right. You can argue that relational model is more useful, that's it.

If you assume that D&D is correct because it reflects how the things really are (subtypes are subsets), then you'd be right, MST(2) should be a compile time error. That is impossible to decide by the system so we throw the complexity back to the user, we wahs our hands, just like D&D wave their hands at the fundamental problems. And they almost "prove" that if a system is to support type in heritance at all, it has to be their inheritance ( bad terminology anyways).

But what we deal with is formal systems, that is according to Dijkstra we deal with complexities of *our own making*, therefore we can't blindly adopt D&D's broken type system cause it is the "correct" one (regardless of the consequences), it isn't neither the correct nor the wrong one, it is more or less useful, and the usefulness we judge it according to specific properties.

The fact that it introduces unneeded complexity for no real benefit, that's what makes it useless in comparison with most type systems in existence.

As a matter of fact, the type system from tutorial D just does not exist,as long as there's no compiler no runtime system, no formal language definition. So I guess we're wasting our time debating it.

Best,
Costin Received on Tue Sep 09 2003 - 18:14:29 CDT