Re: Does Codd's view of a relational database differ from that ofDate&Darwin?[M.Gittens]
Date: Thu, 7 Jul 2005 10:15:56 +0200
Message-ID: <MPG.1d37032c175a87f59896e8_at_news.ntnu.no>
In article <1120666414.650757.194510_at_g49g2000cwa.googlegroups.com>,
boston103_at_hotmail.com says...
> > 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).
Very well. Is my speculation above valid if we apply it, mutatis mutandis (to use Date's slightly pompous phrase:), to the ML example? If not, why not?
> 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.
Sure. I guess you could view possreps as little more than operators/functions on the domain. They are important in order to be able to specify literals, though. In my example, you cannot say Temperature t = 24.5, because 24.5 is a double, and Temperature is not. You'd have to say Temperature t = Celsius(24.5) (not valid Java syntax, of course), where Celsius(24.5) is an expressing denoting the (one and only) Temperature that is 24.5°C (and 76,1°F and 297,65 K). (That expression is called a selector invocation, by the way.)
> > 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.
My Temperature has three possreps; four after my KelvinString introduction. I can make a point, if you will. :)
class Point {
Still Java, so selectors (which more plainly show the possreps) don't
show up. They correspond almost to constructors, but Java constructors
create a new variable (object); selectors merely designate a value (all
of which exist a priori, just like all ints exist without any need to
"create" them). In Tutorial D, you would just specify the two possreps
private double x, y;
public double getX() { return X; } // And getY, setX and setY likewise
public double getR() { return Math.sqrt(x * x + y * y); }
public double getTheta() { return Math.atan(y / x); }
// I need to handle x==0 and so on, but you get the picture.
// setters are also trivial
}
> 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.
No, there isn't---or at least, it isn't union types. Of course, every type/domain is a set of values, and every set can be expressed as the union of other sets. "int" is a union type, it is the union of odd and even numbers, no? But that is trivial.
> > > 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.
No, THAT IS WHAT POSSREPS ARE! 0°C and 273,15 K are ways to represent the same value (not values) of the Temperature type so that the compiler (and the code writer/reader, I might add) could understand it.
> > > 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 ?
Every value must have a representation so that the user can denote it, and the compiler can understand it. This representation could be the same as the representation the computer uses internally, but it shouldn't *have* to be---we might want to change the internal representation later (for performance reasons, perhaps), and existing code should not break because of it. Therefore, the representation used externally is called a possible representation, because it could possibly be used as *the* internal representation as well---we don't know if it is, and we don't care. And there may be other possible representations as well, depending on the needs of our application.
> As I understand, its sole purpose is to
> introduce *multiple* possible representations.
No. You don't need more than one.
> If so, again, why not
> just call the thing a union type ?
Because it isn't. Temperature is not the union of double, double and double, or even of fahrenheit, celsius and kelvin. Point is not the union of cartesian points and polar points. It does not even make sense to speak of such a union, because the set of cartesian points and the set of polar points is the same set---the set of 2D points. (0,4) and (4,90°) is the same point, just like 14 and 0xE is the same int.
-- JonReceived on Thu Jul 07 2005 - 10:15:56 CEST