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

From: vc <>
Date: 6 Jul 2005 09:13:34 -0700
Message-ID: <>

Jon Heggland wrote:
> In article <>,
> says...
> > >> y.f=3.14;
> Can you refer to y's i or c value?
> Let me speculate: Your union type is the union of the int, float and
> char domains (domains being sets of values). Let's make the reasonable
> assumption that they are disjoint, even though a case could be made that
> (e.g.) 2 == 2.0 (and that C consider characters and integers pretty
> interchangeable). In that case, a value of the my_data type could be
> *either* an int, a char or a float, but not more than one at a time.
> Trying to treat it as a char if it is a float, leads to a (run-time?)
> error.

The C example is not a very good one due to C's unsatisfactory type system. I gave it because you said you were unfamiliar with languages having a sound type system(ML, Haskell, etc).

My point was that the component data types are hidden and you have to operate with the resulting type via operators/functions you need to define.

> In contrast, a TTM domain with possreps has in internal representation
> that we don't care about. It has one or more possible representations
> that are always valid, no matter what the value is. This probably
> necessitates a 1:1 mapping between the internal representation and each
> possrep, though I can't recall having seen this spelled out explicitly
> in TTM. In any case, the domain is *not* a subtype of its internal
> representation---Temperature is not a "narrowing" of double. It is
> encapsulated. We can change the internal representation without
> impacting the rest of the world. We can add possreps without breaking
> existing code. Your union type can't do that. It's the magic of OO. :)

When I started talking about union types I had in mind *multiple* possreps as in the cartesian point vs. polar. You do not need u.t. with a single possrep, of course, just multiple operators/functions to produce the desired result. Sorry for the confusion.

> > That's called cheating ;) In Java, you're just narrow the single double
> > datatype by defining accessor/mutator functions on the double d.t..
> No, I don't. I am defining a brand new datatype (class). I am hiding its
> internal representation by declaring it private. I have only used
> doubles for possreps, because that was most convenient. I could have
> used a String, e.g.
> String getKelvinString() { return Double.toString(getKelvin()) + " K"; }
> (Note, however, that my Java example is not entirely correct, because a
> Java Temperature object is a variable, not a value. I also haven't
> considered domain constraints (e.g. no temperature can be below 0 K).
> But that does not impact our discussion much.)

Yes, I've been comparing multiple possreps with union types. One possrep is just a single user defined type.

> > This is
> > different from the possrep example where you define multiple possreps using
> > different data types in a way identical to the union type.
> What possrep example?

The POINT example from the TTM. In one of your messages you've referred to the Point definition although I believe you did not mention multiple possreps. Anyway, I was objecting to the term possrep vs. type (or, in the case of multiple possreps, vs. union types) since there is already established terminology for this sort of things.

> > The ability to say i=14 or i=0xE has got nothing to do with union data
> > types.
> My point exactly! But it has very much to do with possreps. You can
> represent an integer in decimal, or hex, or oct, or binary. Different
> ways of denoting the very same value.

Hold on. 14 and 0xE are ways to represent the same values of the integer type so that the compiler could understand it. It's got nothing to do with the type system, possreps and such. It's like using Arabic vs. Roman numerals. Let's not dwell on it -- it's irrelevant.

> > How is it even relevant to the issue of types?
> It is a demonstration that possrep is a useful concept, that dates from
> before Date. So why not apply it to *all* types? A temperature is a
> temperature, be it measured in F, K or C. A point is a point, be it
> polar or cartesian. A distance is a distance, be it measured in
> lightyears, feet, meters or ångstrøm. An int is an int. 14 == 0xE && 0°C
> == 273.15 K.

Cool. So one uses a user-defined type TEMP, what's the point of the word possible representation ? As I understand, its sole purpose is to introduce *multiple* possible representations. If so, again, why not just call the thing a union type ?

> --
> Jon
Received on Wed Jul 06 2005 - 18:13:34 CEST

Original text of this message