What does a type system need?

I’d like to ask what TTM really needs of a type system. My opinion:

A ‘type’:

  • Is a named set of values and operations on those values.
  • The set of values is fixed, but the set of operations may be extensible.
  • An attribute of a tuple belongs to a type, and every value it can take on is a value of that type. (No NULLs unless NULL happens to be a value of that type).
  • Values are associated with an underlying implementation-defined bit pattern, and every value has a unique bit pattern. Not every bit pattern is a value.

A ‘type system’:

  • Is an interoperable set of types, of sufficient scope for its intended purpose.
  • A minimalistic abstract type system consists of Number, Character, Binary, Tuple and Relation. All of these are ‘infinite’.
  • A practical concrete type system includes members consistent or compatible with common programming language and SQL types, such as Boolean, Integer, Float, Decimal, Time, etc. All of these are ‘finite’.
  • An open type system is extensible by some means to add members that are valuable in a particular problem domain. Otherwise it is closed.
  • Provides conversions from one type to another, which may be ‘implicit’ (preserves all values) or ‘explicit’ (some values lost or altered).

Note that all tuples are of Tuple type and all relations of Relation type. The header is not part of the type, so it must be part of the value.

An ‘expression’:

  • Is a composition of literal values, variable values, attribute values and operations, which can be evaluated to return a single value (closed), multiple values (open) or a (possibly ordered) collection of values (array).
  • Provides support for the chosen Relational Algebra, in particular for creating, extending and filtering tuples and relations (NEW, EXTEND, WHERE).
  • Provides support for an external programming language to evaluate expressions and retrieve values and arrays of values.

That’s a summary of where I’m up to. I don’t see a need for type inheritance, given implicit conversions. I don’t see a need for building the extension capabilities into a new language. The above looks complete, consistent and implementable.

I’m happy with the Rel approach using Java to extend the type system. In that case the type system comprises the built in types, type definitions in Tutorial D code and the jar file that extends the type system.

Leave a Comment

Filed under Rationale

Leave a Reply

Your email address will not be published. Required fields are marked *