Re: RM and abstract syntax trees

"Ed Prochak" <edprochak_at_gmail.com> wrote in message news:1194634928.585870.33340_at_o3g2000hsb.googlegroups.com...
> On Oct 31, 5:23 am, "David Cressey" <cresse..._at_verizon.net> wrote:
> > "David BL" <davi..._at_iinet.net.au> wrote in message
> >
> > news:1193796029.446713.108270_at_k35g2000prh.googlegroups.com...
> >
> >
> >
> >
> >
> > > On Oct 31, 10:06 am, paul c <toledobythe..._at_ooyah.ac> wrote:
> > > > David BL wrote:
> > > > > On Oct 31, 2:46 am, paul c <toledobythe..._at_ooyah.ac> wrote:
> > > > >> Okay, from your original post:
> >
> > > > >> "So RM is forced
> > > > >> to expose the equivalent of pointers directly in the
representation.
> > > > >> Furthermore, the RM has no mechanism for hiding these pointers
or
> > > > >> giving the user an interface that promotes the idea that a node
> > > > >> logically represents a value."
> >
> > > > >> Where does RM ever mention pointers? Eg., What are the pointer
> > > > >> operations that RM supports?
> >
> > > > > I'm associating a "pointer" with the idea to give a thing (like a
node
> > > > > of an AST) some meaningless identifier, and using that identifier
> > > > > elsewhere as a means to uniquely reference that thing. With that
> > > > > *analogy*, RM performs a pointer dereference when performing a
natural
> > > > > join.
> > > > > ...
> >
> > > > Sorry if this seems pedantic (which it is) but RM references things
> > > > uniquely with values.
> >
> > > I have no problem with you being pedantic and like your comments!
> >
> > > Yes RM references things uniquely with values, but pointers are "value
> > > types"! Note the distinction between "pointer-type", "pointer-
> > > variable", and "pointer-value". When a pointer-variable is assigned
> > > a pointer-value, the object being referenced only depends on the
> > > pointer-value.
> >
> > > If you want to be pedantic, I would say it has more to do with the
> > > fact that pointer types have a dereference operator, whereas surrogate
> > > ids in RM do not. But as I said, I was only drawing an analogy with
> > > pointers.
> >
> > > Note that each time a join is used to navigate from parent node to
> > > child node in an AST, we will typically only get a single tuple in
> > > the join result. This follows from the integrity constraints (that a
> > > node must be *exclusive or* a variable, number, addition node etc),
> > > but more easily can be understood using the analogy with a pointer
> > > dereference. The set level manipulation capability of RM (one of its
> > > great virtues) is not being utilised.
> >
> > > In the end I'm more interested in whether you agree with the
> > > conclusion : that RM is ill-suited to represent ASTs.
> >
> > In this whole discussion, I have a big problem understanding what is
meant
> > by "the equivalent of pointers". A pointer is NOT an arbitrary
meaningless
> > identifier. A pointer is an address. If you assign an arbitrary
meaningless
> > identifier to an object for reference purposes, that is NOT the same
thing
> > as referencing the object via a pointer.
> >
> > If you need the concept of arbitrary meaningless identifier in order to
make
> > a point about how RM represents trees, go ahead. Just don't call them
> > "pointers" and don't assert that they are the quivalent of pointers when
> > they are not.
> >
> >
> But they behave like pointers. Most often these "arbitrary meaningless
> identifier" values are generated by a sequence. If you have one such
> value, you often can find other data simply by incrementing of
> decrementing the identifier value. You can manipulate or print the
> identifier value (IOW the pointer value is exposed unlike references
> in some languages.) If that isn't an example of some fundamental
> properties of pointers, then I'd like to hear why not.
>

One of the fundamental properties of a pointer is that you can "dereference" it by using it as an address in an address space, in order to retrieve the thing pointed to directly. There is no corresponding property in sequentially generated arbitrary meaningless identifiers. Received on Fri Nov 09 2007 - 23:29:15 CET