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