Nested value types

    Point centre;
    float radius;
};

Some people on this NG have suggested that tuples should take a back seat role and in the type system all one needs are relations. But consider:

relation Circle2
{

    Point centre;
    float radius;
};

This seems wrong because circle values are not propositions.

Now consider:

relation Circle3
{

    string name;
    Point centre;
    float radius;
};

It seems to me that a relation variable of type Circle3 can be regarded as a dynamic collection of named variables that hold circle values.

This brings me to the main point of this post. Consider the following to represent a chapter of a book as an abstract mathematical value:

tuple Chapter
{

    string title;
    list<string> paragraphs;
    list<Chapter> subChapters;
};

It is assumed that a value of type list<T> is an ordered sequence of values of type T.

A tuple can be regarded as a way to statically compose values from values, and set<T> and list<T> are two ways to dynamically compose values from values.

The interesting thing is that a value of type Chapter is able to represent any tree structure in the form of pure nested values, without anything that looks remotely like a pointer to a variable. Nevertheless I would call the structure dynamic not static because it isn’t fixed by the static type.

I find this recursive type definition of a chapter simple and elegant. By contrast a relational encoding of a tree structure of chapter values will be forced to give the chapters names, and it is possible to interpret the data as containing identifiable dynamic variables connected up with pointers.

My thinking at the moment is that the RM or the HM (Hierarchical Model) on its own is inadequate, and what’s needed most generally is both.

I think tree structures are very important in certain applications. Unfortunately the HM often doesn’t provide a satisfactory solution to the representation of some complex value types such as a TriSurface. I would like to think of this as a pure value type so ideally a Trisurface value can be represented without any need to introduce meaningless identifiers. It is indeed possible to define a “pure” HM like this:

tuple Vertex { float x,y,z; };
tuple Triangle { Vertex v[3]; };
tuple TriSurface { set<Triangle> triangles; };

However this is badly over-determined, because the triangles have a strong integrity constraint that they meet each other, which greatly reduces the degrees of freedom in the model. Therefore in practice TriSurface models tend to reduce the degrees of freedom by representing all the vertices separately, and multiple triangles may reference a shared vertex. Of course that gives the vertices identity within the context of the representation of a TriSurface value, and the RM seems appropriate. However, the relation tuples interpreted as propositions seem to state nothing more than a binding of a value to a variable that only exists in the scope of defining a TriSurface value. Yuk! Received on Mon Jul 14 2008 - 12:02:45 CEST