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

Hi,

I found an article by H.Darwen (
http://web.onetel.com/~hughdarwen/TheThirdManifesto/taamoti.paper.pdf ) that clarifies the issue a bit. Apparently, the kind of user defined types T.T.M uses is more of object-oriented (Java, etc) than functional flavour (ML, etc). They do not define their OO type system very well, but one can gather that Java interface types are quite similar. If so, then the POINT example can be translated to pseudo-Java so:

interface POINT {
  Cartesian(x float, y float); -- named "constructors" (not offered by Java of course)
  Polar(r float, theta float);

  float get/set_x ...
  float get/set y ...
  float get/set r ...
  float get/set theta

In this case, there are no component types and the type is determined solely by its collection of constructors and getters/setters. Still, I find the notation and the very words "possible representation" quite confusing. Why not use the vocabulary familiar to many OO programmers and talk about constructors and accessors/modifiers directly ?

My subsequent comments rely on the notion of type I was able to gather from the article.

Jon Heggland wrote:
> 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?

[the point] I was under impression that you wanted to compare TEMPERATURE with RATIONAL without mapping temperature -> rational first, that's all.

[the second IF ] Yes, it would.

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

Yes, you may have ambiguity issues. It's better to define record types with different field names:

type celcius = {c:rational}
type kelvin = {k:rational}

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

In what specific definition ? I do not see the context. I gave at least three:

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

What clashes with what in the above examples ? What specific example you are asking about (1) or (2) ? If it's (1), then {c=15} will have the type "celcius" and Celsius {c=15} will have the type "temperature". If it's (2) then {c=15} will naturally have the type temperature.

Overall, it was a useful discussion. Now it appears to be quite clear that T.D uses types similar to Java "interface types" using nominal subtyping (by name rather than by structure). Whether relying on "object types" with inheritance and subtyping is preferable to functional/algebraic types is yet to be determined ;) Received on Mon Jul 11 2005 - 17:47:56 CEST