Re: RM and abstract syntax trees

"David BL" <davidbl_at_iinet.net.au> wrote in message news:1193833888.092224.27420_at_k35g2000prh.googlegroups.com...
> > 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.
>
> Pointer taken!
>
> So you want to reserve the word "pointer" specifically to where a
> memory address is involved on a Von Neumann architecture? Since it's
> merely a terminology issue I won't disagree with you. I presume you
> would say that a C++ smart pointer that binds to its referenced object
> using a key in a red black tree must not under any circumstances be
> regarded as somehow being the "equivalent" of a pointer or being
> "analogous" to a pointer.

My understanding of the meaning of "pointer" is not quite as narrow as my understanding of "memory address".

Specifically, in the internals of databases, the file space where data is stored is often organized into what I'll call a "database address space". In one particular DBMS,
DB addresses consist of Storage Area Number, DB Page Number, and DB Line Number. These three numbers, taken together, are sufficient for the DBMS to retrieve the item pointed to in one disk read (or zero disk reads if the page is already cached).

If the database is a hierarchical or some other graph based DB, items pointed to include "records", and "records" contain pointers to other records. The pointers constitute what another contributor has called the "plumbing" that ties records together.

In a relational database, the only visible linkages that tie rows together are ones established and maintained by the data contained in the rows, and DB address is specifically not one of the types supported and exposed. In one soi disant "relational DBMS" the builder can specifiy this "DB address" as the data type of a column, and use it to tell the DBMS where to look, instead of what to look for. The documentation cautions the designer not to use this feature without understanding the consequences, but I'll leave it at that.

All of this is a rather precise analogy to what you are calling "memory address is involved on a Von Neumann architecture". But the addresses are stored on disk, and refer to addresses that map into disk addresses, rather than memory addresses as such.

Hope this helps. Received on Wed Oct 31 2007 - 14:27:04 CET