Nested value types
- From: David BL <davidbl@xxxxxxxxxxxx>
- Date: Mon, 14 Jul 2008 03:02:45 -0700 (PDT)
In the following I’m using the definitions of value, variable and type
described by C.Date. Values are eternal and immutable. Variables
are holders for values that exist in some context. Values and
variables are both typed.
Let a “pointer” be any reference to a variable in some context.
Let x be called a subvariable of y if x encodes part of the value
encoded by y. Note therefore that changing x causes y to change as
well.
Consider the following type definition for a 2D point:
tuple Point
{
float x,y;
};
A Point value is composed from nested values. Variables don’t enter
into the picture.
A Point variable has subvariables for the x and y coordinates.
This can be used to help define a circle type:
tuple Circle1
{
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!
.
- Follow-Ups:
- Re: Nested value types
- From: Marshall
- Re: Nested value types
- Prev by Date: Re: Guessing?
- Next by Date: Re: Guessing?
- Previous by thread: Re: Vendo Cartridge para impresoras EPSON, ORIGINALES
- Next by thread: Re: Nested value types
- Index(es):
Relevant Pages
|
