Re: RM and abstract syntax trees

On Nov 13, 5:34 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
> On Nov 12, 10:36 pm, David BL <davi..._at_iinet.net.au> wrote:
>
> > On Nov 13, 1:54 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
>
> > > What is the larger context in which you are still arguing
> > > with me? What is the point you are trying to prove? I have
> > > already made it quite clear that I see similarities between
> > > pointers and foreign keys. Is there more? Because I don't
> > > understand why this conversation keeps going on.
>
> > I had missed your post on the 10th and when I cam across it today I
> > disagreed with it, so I responded. Sorry! I actually find the matter
> > quite boring. You are arguing as well so don't call the kettle
> > black! I could just as easily ask you what you are trying to prove.
>
> You didn't answer my question.

You are stating certain characteristics and claiming they are fundamental differences. I don't agree with some of your arguments. I wouldn't say I'm trying to prove an interesting point!

> > > Your core dump example is inapplicable. Yes,
> > > if you preserve *the entire address space* then pointer
> > > values will still be valid. Which says nothing about
> > > serializing object graphs, which is what *I* was
> > > talking about.
>
> > Serializing object graphs (as I interpret it) encompasses the special
> > case of not translating pointer values.
>
> > I thought your argument was this:
>
> > Sending object graphs between processes (always)
> > translates pointer values
> > Sending relations between RDBs (never) translates
> > key values
> > Therefore there is a fundamental difference.
>
> > Sorry to be up front but there is a flaw in that logic.
>
> You didn't say what that flaw is.

If you replace "always" with "mostly" (or "never" with "hardly ever") the argument is merely statistical.

> > > If you want to merge two databases with different semantics,
> > > you'll have to remap some of the values in the database. You
> > > might have to do this with all kinds of values, not just keys.
> > > The remapping of keys is just a particular (and not in any
> > > way special) case of the fact that you have to have a new
> > > unified semantics for the merged databases, and remap
> > > the old ones into it. (Or you might keep the semantics of
> > > one of them and just remap the other.) If you are not
> > > merging two databases, then the remapping you bring
> > > up is inapplicable. If you *are* merging databases,
> > > then you have to do this remapping whether or not
> > > you are serializing the database as well. So this point
> > > says nothing about serializing databases.
>
> You didn't respond to this argument.

When I raised the issue of mapping keys I was thinking of the case of sending an AST between two RDBs having identical schema and semantics. The remapping of keys can be necessary because of clashes that have nothing to do with a mismatch in the database semantics. I regard this as a symptom of the use of "meaningless" node identifiers. I find it very similar to the problem of sending object graphs between processes. The underlying problem is a clash in the address spaces when merging the data. Naturally physical pointers will be far more likely to require remapping than logical pointers. However that is merely a statistical argument. Strictly speaking that is an orthogonal characteristic.

If anything I find serialisation of databases versus serialisation of object graphs reinforces the similarities! Received on Tue Nov 13 2007 - 11:20:41 CET