Re: The Practical Benefits of the Relational Model
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'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.
> Mixing them in the way you describe has led to massive
> confusion on the subject.
Kind of patronizing, don't you think ?
> 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.
>>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.
>>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.
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