Re: The Practical Benefits of the Relational Model

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Tue, 01 Oct 2002 11:52:13 -0700
Message-ID: <3D99EEDD.40203_at_hotmail.com>


Nathan Allan wrote:
> Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<3D94EE6E.5020804_at_hotmail.com>...
>
>

>>To begin with nobody has implemented a relational system as yet.

>
>
> I suppose the last several years of my life, and the lives of my
> co-workers were spent doing nothing. I wish people would stop saying
> that! Just to be perfectly clear: WE HAVE a commercial relational
> database management system.

I believe your web site talks about a data access engine and some data access components. Which one is it ?

>>I'm sure we disagree here, although I simpathize your view. Let's be 
>>clear: I'm not saying that you are wrong. You can define a framework 
>>(model) in which types are sets of values by definition. Nothing wrong 
>>with that.

>
>
> It turns out that we do have different definitions of type after all.

Types may have different precise definition in different type systems, but they do have a certain common functionality, that you have to provide. This is described briefly in "Type Systems".

Stating that "my definition is different than yours" is not very helpful. I'm open to all definitions that come with a formal system or even a slightly informal one, as long as we can understand the logical implications, we can compare advantages and disadvantages.

> I certainly don't consider a implementation contract (interface) a
> type, and the implementation is (operators are) also orthogonal to
> type.

Either you confuse types with implementation, or you accuse me of confusing the two.

Implementation is orthogonal to type is not *logically* the same as operators are orthogonal to type. Unless you have the identity implementation == operators, which is not helpful at all, not to mention that is not an acceptable use of English language.

Let's see an example ("real world" :) ). I have a cryptographic algorithm that works over finite fields. Let's rather say informally:   P(private_key)= public_key.

Now I have the mathematical algoithm for P. Obviously, I don't want to write that code again and again, for different finite fields, therefore I'd say that the algorithm should be written *once* and for all for the most generic type FINITE FIELD.

Now do you accept that FINITE FIELD is a type ? If you construct for me a set of elements, can I verify that they indeed form a finite field, in other words, can you really separate the set from the structure defined over it ?

By the way, how would you declare such a program in D4 ?

> Mixing them in the way you describe has led to massive
> confusion on the subject.

Kind of patronizing, don't you think ?

I think the subject is not confused at all, unless you are confused about the subject, or you select the wrong references to prove your point. If you take time to study the _scientific_ work in the field you'll see that there's a rather large consensus.

> Unless we can agree about what a type is,
> additional discussion is likely to be fruitless.

No, we dont need to agree what _exactly_ a type is, unless you want to impose on me the view of Mr. Date. You'd have to have some darn good arguments, because, you know, there's an established discipline at the confluence of Logic, Algebra and Computer Science that has come up with an established theory and lots of *practical* result, and it doesn't operate by Mr. Date's definition. In the meantime TTM has come up with a   partial theory and no practical results. Where by result I mean a practical implementation of the system that is able to prove its usefulness. Ideally, as in the case of ML, the actual type systems should be _provable_ safe and sound.

A precise definition of type will be different in different systems, each with its own benefits. But we have to agree what are the essential roles and benefits of having a type system. And you can evaluate how Mr. Date's proposal compare with other type systems.

So far you have avoided to acknowlegde even the most obvious limitations of Mr. Date's proposal, like subtyping is undecidable.

>>By the way, how do you define values? As far as Mr. Date is concerned 
>>the values are immutable and carry their type with them.  Kind of 
>>circular don't you think ?

>
>
> Type and value are inextricably linked. You can't talk about one
> without the other.

"Inextricably linked" sounds very informal to me. You can't say in Mathematics that 2 definitions (type and value) are "inextricably linked". Whenever you have a recursive definition or a system of recursive definitions, you have to actually show the way out of recursion.

If you know French, I'd strongly recommend an article: Giuseppe Longo: Cercles vicieux, Mathématiques et formalisations logiques. It's rather short and very dense and related to type systems. Maybe it can change your view on "inextricably linked".

>>But the real question is how useful that system is? (Assuming you can 
>>get past the circularity between values and types). It turns out that it 
>>is not really, as you probably found out when you decided not to 
>>implement features of the type system that are essential.

>
>
> You are going way overboard here (and in the rest of your posting).
> We did not "decide" not to implement features of TTM's type model...
> the actual process was that we put basic scalar types in and it was so
> easy to provide some of the capabilities of subtyping that we couldn't
> resist.

Do you actually verify the subtyping relation A <: B ? Can you identify when 2 distinctly declared types are equal? Do you provide automatic inference of the type lattice ?

More to the point: do you really have a choice about those issues within the framework of TTM "type inheritance model" ? Or to say it more bluntly, is it implementable ?

> --
> Nathan Allan

Costin Cozianu Received on Tue Oct 01 2002 - 20:52:13 CEST

Original text of this message