Re: Nested value types
- From: Marshall <marshall.spight@xxxxxxxxx>
- Date: Mon, 14 Jul 2008 10:29:30 -0700 (PDT)
On Jul 14, 3:02 am, David BL <davi...@xxxxxxxxxxxx> 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
.
- Follow-Ups:
- Re: Nested value types
- From: David BL
- Re: Nested value types
- References:
- Nested value types
- From: David BL
- Nested value types
- Prev by Date: Re: Guessing?
- Next by Date: Re: Guessing?
- Previous by thread: Nested value types
- Next by thread: Re: Nested value types
- Index(es):
Relevant Pages
|
Loading
