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

In article <1120833398.573397.92590_at_o13g2000cwo.googlegroups.com>, boston103_at_hotmail.com says...
> > > You cannot apply any function dealing with ints to the value of the
> > > my_data type, you need to define functions capable of handling values
> > > of the type you've just defined.
> >
> > Then what use is it? What can you do with it except assign values to
> > variables of that type? There seems to be at least some operators
> > associated with it by default, since you can say x.c='f' and y.f=3.14.
> > What is the type of the expression x.c? Is it char or my_data? If it is
> > my_data, there at least is an operator to convert char to my_data. Why
> > isn't there one to to do the opposite? Can you compare a my_data value
> > to a char, int or float?
> >
> In order to do anything with any user defined type, one has to define
> operations/functions that can handle elements of the newly defined
> type. What can you do with the T.D. TYPE without defining functions
> over the type ?

Express literals, perform assignments, check for equality, access components of the representations.... But I guess that is a matter of convenience and syntax; not very important. I'm not sure what I meant by that question. :) Perhaps I felt that the types you constructed the union type over didn't matter all that much, since you have to explicitly create accessors anyway.

> 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).
> > > E.g. you'd need to define conversion functions (my_data->int,
> > > my_data->char, etc) and any additional functions you'd want to have.
> >
> > How would the definition of such a function look?
>
> Given datatype t = L1 of int| L2 of float;
>
> fun get_int(L1 x)= x | get_int(_) = /*raise error */
> fun get_float(L2 x) = x | get_float(_) = /*raise error*/

Thanks. This makes it pretty clear that a t value is either an L1 or an L2. I suppose you have some mechanism for determining which it is?

> > > Let's use the Tutorial D example instead in order to avoid Java type
> > > system pecularities. There, TEMPERATURE is defined as having one
> > > possible representation:
> > >
> > > TYPE TEMPERATURE POSSREP CELSIUS ( C RATIONAL ) ;
> >
> > ...and possreps FAHRENHEIT ( F RATIONAL ) and KELVIN ( K RATIONAL ).
>
> There was no 'and possreps FAHRENHEIT ( F RATIONAL ) and KELVIN ( K
> RATIONAL )' in my discussion.

Temperature was *my* example, with three possreps. I don't understand why you ignored the two other.

> > Great. Is your temperature a union type?
>
> Certainly not. The original example from which I derived mine has only
> one component datatype (one "possrep").

So your position is that a datatype with just one possrep is not a union type, but one with multiple is? Then I don't see how you can claim they are the same concept.

> > (By the way, I find it counter-intuitive to treat celsius as a datatype.
> > Celsius is a representation of temperature.)
>
> I'll ignore the remark for now since we already have more than enough
> "representations" to talk about.

Fair enough, but I am not trying to introduce another meaning of the term "representation". It is the same I have used all along.

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

> > > Now, to the POINT example. The T.D. example:
> > >
> > > TYPE POINT
> > > POSSREP CARTESIAN( X RATIONAL, Y RATIONAL )
> > > POSSREP POLAR ( R RATIONAL, THETA RATIONAL ) ;
> > >
> > > .. can be expressed in ML as:
> > >
> > > datatype cartesian = {x:rational, y:rational}
> > > datatype polar = {r:rational, theta:rational}
> > > datatype point = Cartesian of cartesian|Polar of polar
> > >
> > > The last datatype (point) is called a union type because it's a union
> > > of two types, cartesian and polar. To designate a value, one would
> > > say:
> > >
> > > Cartesian {x=1, y=2} or Polar {r=3, theta=4}. naturally, both values
> > > would be of the point type.
> >
> > But you have three types instead of just one. And I guess comparing {x=
> > 3,y=0} and {r=3,theta=0} would be a type mismatch error, while comparing
> > Cartesian {x=3,y=0} and Polar {r=3,theta=0} would yield true. Or would
> > it?
>
> Of course there are three type (actually more, but that's beside the
> point), two component types and one resulting type as, in my opinion,
> there are in the T.D. POINT example.

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

> What do you mean by comparing ?
> What specific comparison function do you have in mind ?

Equality.

> > In contrast, any value
> > in the possrep system has a representation in *all* of the possreps of
> > its type.
>
> That's odd. Are you saying that a hypothetical implementation would
> store all the "possible representations" for a given value ? What
> would be the point of that ?

No, it wouldn't *store* them all (or we don't really care how it is stored, but it would be a bad idea to store more than is needed). But it would be able to produce any of the possible representation, based on the (single) stored representation. Like my Java Temperature example. Moreover, each of those representation would denote the SAME VALUE. As in, the temperature outside my window at this moment is the same, regardless of whether I express it in C, F or K.

> But assuming the unlikely mental model is indeed correct, we can look
> at a type defined by multiple possreps as just a record type
> consisting of other record types (or "structures" using the C
> vocabulary):
>
> datatype cartesian = {x:rational, y:rational};
> datatype polar = {r:rational, theta:rational};
> datatype temperature = (cartesian, polar); <-- instead of "Cartesian of
> cartesian | Polar of Polar" just a record with two types

No; this record would be able to "store" two different points (I assume that's what you mean, not temperatures). A TD POINT isn't. It "stores" a single point. With two (or more) equivalent representations.

> Btw, does the
> T.D. say the definition implies that two possreps *exist* at the same
> time or it's your own interpretation ?

I don't have the books with me here at home; I'll check on monday. (I only have the 1st ed. of TTM, though.) I have considered this obvious, though. What would else be the use of them? In all my years of programming, I have never used union types (and I don't think I'll start now:), so that interpretation did not occur to me. I also haven't seen any TD syntax for determining whether a POINT is a CARTESIAN or POLAR, which would be needed for type safety.

> OK, let's approach the problem from another side. A type is a set.
> When we say TYPE T POSSREP P(X INTEGER), how T is related to P ?
> Obviously T is a set which means that something defined by "POSSREP P(X
> INTEGER)" must be a set too. What kind of set this is ? How would you
> describe its elements ?

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?

It becomes more complicated if you have more than one possrep, because then you have to provide mappings between the possreps. But it is not very difficult, as my Java Temperature example shows.

> > You said, "14 and 0xE are ways to represent the same values of the
> > integer type".
>
> "14" and "0xE" are strings that are mapped to the same integer by the
> compiler in a specific language implementation. A human who wrote the
> function told the computer to do so. Per se, they do not have any
> specific meaning beyond just being strings of characters.

Yes. Just like a human told the computer to map (the strings, if you will) CELSIUS(0) and KELVIN(273.15) to the same TEMPERATURE.

> > "Possrep" is definitely not a substitution for "type", and I have never
> > said so! What are 14 and 0xE in your union type world? Values of
> > different type?
> >
>
> "14" and "0xE" are strings and as such are of the same type, but see
> above.

Yes, see above. :)

> See above. "14" and "0xE", being members of the string type, have got
> nothing to do with union types.

Again, my point exactly. Possible representations have nothing to to with union types.

(I think you are cheating a little by using "14" and "0xE" instead of 14 and 0xE---in very many programming languages, those are different values of different types. Or that you are sidestepping the issue with the sophistry that everything is strings anyway. Which is true in some sense, but irrelevant for the discussion at hand. In Java, 14 is an int. "14" is a String. 0xE is the same int. "0xE" is a different String.)

> > No. With a union type, a value is *one* of the types involved in the
> > union. With a multiple possrep type, a value has *all* of the possible
> > representations.
>
> See above (my question on whether the T.D. supports your interpretation
> and the "record type").

Yes, I'll check that out. I'm pretty confident I'm right, though. :)

-- 
Jon