Re: Nested value types

On Jul 15, 1:29 am, Marshall <marshall.spi..._at_gmail.com> wrote:
> 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.

I’m not sure. It doesn’t make sense to edit a value because values are immutable. One can only edit a variable.

I can see it makes a lot of sense to say that variables may have subvariables. Eg a Point variable may have subvariables for its x,y coordinates. Similarly a TriSurface variable may have identifiable subvariables for the vertices – so no contradiction with a user that grabs a vertex and moves it.

However I find it questionable to say that a TriSurface value introduces a context for dynamic variables, and yet it seems implicit in the relational representation. Perhaps I need to think about it differently.

On another note...

A value type like list<T> defines the set of permitted values and a set of operators such as binary + to concatenate two list values into a single list value, or an index operator that retrieves one of the elements (as a value) of a given list value.

However it doesn’t specify the available mutative operators on variables of type list<T>. For example I can imagine various options:

1. Allows assignment of the entire list value.
2. Allows deletion of elements and insertion of elements as values
3. Exposes the elements as subvariables to allow them to be directly modified.

There seem to be different ways to skin the cat here. For example, (2) on its own is sufficient to allow a variable to reach all possible list<T> values.

Now here’s my question: Do you think it’s permissible for the type system to allow for controlling the available mutative operations on variables? Presumably it muddies it up somewhat. I have wondered whether this is somehow related to the possreps idea. Received on Tue Jul 15 2008 - 04:36:51 CEST