Types as sets

According to the functional data model a variable such as

F : Integer := 1;

should be viewed as syntactic sugar for the function

$f$ : {} $\to$ Integer; $f()$ = 1

The type, Integer, is thus simply a set of values representing the co-domain of $f$. Therefore, in the case of

G : set of Integer := {1, 2, 3};

one has to view set of as an operator which results in the powerset of its argument. Hence, the above is syntactic sugar for

$g$ : {} $\to$ {$s\; |\; s\; \subseteq$ Integer}; $g()$ = {1, 2, 3}

A consequence of this view of types is that types A and B where

A = set of Integer; B = set of Integer

represent the same set of values and are thus identical.

Hence, according to the functional data model, types are simply sets of values which need not be disjoint. This view of types is in marked contrast with the long standing ``axioms'' of language designers, namely:

• A value belongs to one and only one type[2].
• Types are not sets[4].

The full consequences of abandoning these ``axioms'' are examined by the author in another paper[7]. The main conclusions drawn there are that a consistent language design based on the view that types are sets that need not be disjoint:

• must use structural type equivalence rules
• cannot be completely type checked at compile time
• must separate operators from types
• must treat types as first class values
• must be fully polymorphic
• must allow types to vary at run-time
• must support abstract data types in a non-traditional way

This paper argues that the following syntax for declarations would suffice to declare types, constants and variables in a programming language design based on the functional data model.

constant-definition =
identifier `=' expression
variable-definition =
identifier `:' expression [`:=' expression]
expression =
expression {(`$$' $|$ `$$' $|$ `$-$') expression} $|$
(set $|$ sets) of expression $|$
(list $|$ lists) of expression $|$
(map $|$ maps) from expression
{`,' expression} to expression $|$
set-value $|$ non-set-expression

Note that no special syntax is needed to declare types. Where a type is normally expected, any expression resulting in a set of values will do. Type names can be introduced by declaring named constants with sets as values.

Naturally, some types will have to be predefined. The following seems the most widely expected:

{True, False} = Boolean $\subset$ Entity
Integer $\subset$ Number $\subset$ Entity
Character $\subset$ String $\subset$ Entity

where Entity denotes the universal set (the set of all possible values) and

Boolean $$ Number = Boolean $$ String =
Number $$ String = {}