Re: Nested value types

On Jul 14, 3:02 am, David BL <davi..._at_iinet.net.au> wrote:
> 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.

As far as I know, I'm the only person who has suggested this. :-)

I would propose a shorthand syntax for specifying a relation as having exactly one member. At which point, tuples don't serve any function any more. (In the type system.)

A similar issue exists in ordinary set theory. There is usually a primitive is-a-member-of relation, with subset defined in terms of that, but it's also possible to have is-a-subset-of as a primitive, and define membership from that.

> But consider:
>
> relation Circle2
> {
> Point centre;
> float radius;
> };
>
> This seems wrong because circle values are not propositions.

You'll have to be more specific before I can respond.

> 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.

Kinda. I would propose that you don't get too concerned with this. The same issue (minus the "dynamic" part) already shows up in your Point type. Are the x and y components contained variables? In the end I think the question doesn't really matter.

> 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.

Yes. (For the appropriate definition of "any.")

> Nevertheless I would call the structure dynamic not static because it
> isn’t fixed by the static type.

Just so. I use the same terminology myself for classifying trees: "static structure" and "dynamic structure."

> 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.

I'm not thrilled with your terminology but I know what you mean. In fact there have been some meaty threads in the past around "abstract identifiers" (and some less-than-meaty ones as well) and I specifically recall Jan Hidders providing some references to some academic papers with some results along these lines.

> 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!

I hear you, but I have tended to notice that this aesthetic reaction is usually over-strong. Consider: if we bring this 3D object into an editing program, and grab a vertex and move it, what should happen? We would want all the associated triangles to move, would we not? This suggests that the vertex really does have an identity.

Marshall Received on Mon Jul 14 2008 - 19:29:30 CEST