Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]

In article <BtidnUZL-45RfUzfRVn-uQ_at_comcast.com>, boston103_at_hotmail.com says...
> >> As to comparing apples with oranges, can you compare TEMPERATURE with
> >> RATIONAL ?
> >
> > Not directly, of course, but it's not a problem either. It seems you
> > know TD syntax better than me, but isn't this approximately right?
> >
> > VAR T : TEMPERATURE;
> > VAR R : RATIONAL;
> > T := CELSIUS(23.5);
> > R := 23.5;
> > IF THE_CELSIUS(T) = R .... // true
> > IF THE_KELVIN(T) = R .... // false
> > IF T = R .... // compilation error: type mismatch
> >
> > I think some D implementations use the syntax T.CELSIUS instead of
> > THE_CELSIUS(T).
>
> The same is possible in any language that can extract the component to be
> comapred of course.

The syntax is not important. But what was the point of your question? And isn't it so that if TEMPERATURE were a union type, the second IF would cause an error?

> >> > > datatype temperature = {c:rational} and describe a value of the type
> >> > > temperature as just {c=10}.
> >> >
> >> > I guess I really should learn ML, but.... Can I now define a datatype
> >> > coloumb {c:rational}? How can celsiuses and coloumbs then be
> >> > distinguished? If I can't, what is the use of defining the datatypes as
> >> > opposed to just using rational?
> >>
> >> Of course, you can. They'll be distinguished by their tags {celsius,
> >> coloumb}.
> >
> > I'm sorry. When you said "describe a value of the type temperature as
> > just {c=10}", I though you meant just {c=10}, not celsius {c=10} or
> > whatever. Where does the celsius tag enter into your example? Or do you
> > mean the datatype names "temperature" and "coloumb"?
>
> OK. In ML (or many other P/L.s), we can have a *record* datatype:
[snip]
Yes, that is pretty clear.

> Now, to define a point constant, one would say: Cartesian {x=1, y=2} ( or
> maybe Polar {r=5, theta=6}). If one just said {x=1, y=2}, the resulting
> constant would be of the cartesian datatype, not of the point type.

I think you misunderstood my question. You say now that {x=1, y=2} is a Cartesian value, presumably given by the name and number of its components. I asked if you given a datatype temperature {c:rational} could create another datatype coloumb {c:rational} without worrying about "collision". If {c=12} is a valid value/constant/literal, it seems you cannot, since you wouldn't be able to distinguish between temperatures and coloumbs. I was then further confused by your statement that they would be distinguished by their tags, as it seemed to me that only union types have tags, and neither temperature nor coloumb is a union type.

> Let's assume (as I did in my earlier example} that we have only one possrep:
>
> TYPE CELCIUS POSSREP (C RATIONAL).
>
> There are two possible translation into ML:
>
> 1. datatype celcius = {c:rational}
> datatype temperature = Celcius of celcius
>
> A constant: Celcius {c=15};
>
> A little bit silly (a union type with only one component plus a record
> datatype) but closest to the the original TD example.
>
> 2. datatype temperature = {c:rational}.
>
> A constant {c=15}.
>
> We've defined a record type with one field. No need for a union datatype.
> That's what I meant by "just {c=10}"

Yes, and my question was whether that means you have to worry about name clashes between components of different record types.

> > Not in my understanding of TD. Given your definition, CARTESIAN and
> > POLAR are not types; you cannot define variables of those "types". The
> > expression CARTESIAN(2,4) has type POINT, as do the expression POLAR
> > (4,5).
>
> That is correct. In TD , you cannot use the CARTESIAN and POLAR as
> datatype names in order to define independent values/constants (as you could
> do in ML by virtue of having exposed type names). But does it make a
> substanial difference with respect to undertanding what those components are?

I think so---the difference between types and representations. I wouldn't use the word "components", though.

> > T is a set. P is a mechanism (sorry about that vague word) for denoting
> > the members of that set: T = { P(X) | X element_of INTEGER }. P is not a
> > set. You might perhaps say is is a mapping from INTEGERs to Ts?
>
> OK, what kind of mapping is it ? Could you give a "for example" ? Let's
> assume we have a small domain/set: MY_INTS= {1,2,3}. Now, we define:
>
> TYPE T POSSREP P(X in MY_INTS)
>
> What is T ?

Assuming "in" does not mean anything new,

T = { P(1), P(2), P(3) }.

-- 
Jon