Re: relations aren't types?
Date: Thu, 15 Jan 2004 13:52:45 -0800
Message-ID: <bu723k$eaoda$1_at_ID-152540.news.uni-berlin.de>
Adrian Kubala wrote:
> Joe "Nuke Me Xemu" Foster <joe_at_bftsi0.UUCP> schrieb:
>
>>"John Jacob" <jingleheimerschmitt_at_hotmail.com> wrote: >> >>>The OTHER type IS the scalar type. Dates as structures don't exist, >>>only the components of the possible representation, i.e., the year >>>component, the month component, etc.,. Dates as strings are not >>>dates, they are strings. It's just that an operator exists to >>>extract the string representation of a date from a given date value. >> >>We're neither supposed to know nor care how a "scalar" date type is >>implemented "under the blankets". It could be a structure, a string, >>a count of days since 1899-12-30, seconds since 1970-01-01 midnight >>UTC...
>
>
> These aren't types you're talking about, according to standard CS
> definitions. A type has to have values.
>
> It seems like we're going in circles, so if I hear either of you say
> "scalar" I'll just remind myself that you're talking about a type class
> or abstract data type as seen from the point of view of the library
> user.
Let me help you move forward.
Since a type has to have values and a values has to have types, the way to construct both values and types is through a set of *primitive* values and *primitive* types, together with primitive operations, i.e. forming an initial algebra that are bootstrapped into the system.
Those will be your first candidate to be called "scalars" as per D&D terminology.
In addition to the primitive values, you have "means of combination" or "means of composition", so that you can combine the primitive values into new values and new types and specify new operators.
Technically, the means of combinations can be as simple as:
cons, car, cdr
or can be just one:
lambda (as in lambda abstraction)
or can be as complex as:
array, record, union, relation, tuple Received on Thu Jan 15 2004 - 22:52:45 CET