Re: relations aren't types?
Date: Mon, 12 Jan 2004 18:27:09 -0500
Message-ID: <V7SdnT-sLdvhsJ7dRVn-hg_at_golden.net>
"Adrian Kubala" <adrian_at_sixfingeredman.net> wrote in message
news:slrnc068s0.vjp.adrian_at_sixfingeredman.net...
> Bob Badour <bbadour_at_golden.net> schrieb:
> > "Adrian Kubala" <adrian_at_sixfingeredman.net> wrote in message
> > news:slrnc04jos.r0b.adrian_at_sixfingeredman.net...
> >> John Jacob <jingleheimerschmitt_at_hotmail.com> schrieb:
> >> > I think this is the real power of the type system in TTM. I can
> >> > expose both in a single type. I can treat a scalar value as a whole
> >> > by invoking operators that take arguments of that type, or I can
> >> > access the components of some specific representation of the type and
> >> > manipulate those. I think that most type systems have a severe
> >> > short-coming here because they equate the physical representation of
a
> >> > given value with the logical representation.
> >>
> >> I don't see how you can write functions which operate on dates without
> >> knowing something about the structure of the date. How would you write
> >> "year" without being able to extract the year from a date?
> >
> > Suppose I have a date type physically represented as a large integer
type as
> > the number of days since July 19, 1965.
> >
> > How is the year part of the structure of that date type?
>
> It's not, which is exactly why I need to know the structure (a large
> integer) in order to write a function which returns the year.
The whole point is only the person who physically implements the type needs to know this information, and in many cases a system can automate the physical implementation doing away with that one lone person.
Nobody else needs to know anything about the physical structure. One only needs to know that a Year operation exists and that it returns a year. If year is a component of a possible representation, one needs to know that one can derive a new date by changing only the year. Received on Tue Jan 13 2004 - 00:27:09 CET