Re: Values have types ??

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

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

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

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}.

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 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) ???

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

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 Wed Sep 10 2003 - 01:14:29 CEST