[sc34wg3] Possible TMRM issue

Robert Barta rho at bigpond.net.au
Tue Mar 21 23:03:28 EST 2006


On Tue, Mar 21, 2006 at 10:53:03PM +0100, Lars Marius Garshol wrote:
> 
> * Robert Barta
> >
> >Good thinking, but no. Once the proxy is 'flattened out' (we only have
> >in it there labels and primitive values) the 'computation' of the  
> >label
> >is trivial. No complexity here in terms of climbing down something or
> >following up references.
> 
> Well, obviously. But in the case where we have two proxies with  
> labels A and B as follows:
> 
>   A: {(B, "bar")}
>   B: {(A, "foo")}
> 
> Won't the value of A's label here depend on the label given to B? And  
> vice versa?
> 
> I won't be too surprised if the answer is "no", I just haven't been  
> fully satisfied that it is yet.

The answer is "no". :-)

Labels are really only like number plates on cars, except that if you
fiddle around with the car (change wheels, for instance), then you
actually have another car, so another proxy and so with a different
label.

But if you have one given constellation of a car (wheels, motor, gear,
...), then to 'compute' (or assign in some way) a label does not bear
any complexity itself.

In your example above

   A: {(B, "bar")}
   B: {(A, "foo")}

the proxy labelled with A only consists of a single property (B =>
"bar"). To 'compute' a label for A you only may want to use the following
input:

    the label B
    the string "bar"

Maybe you just convert the label B into a string "B" and compute from
there, maybe you - for some reason - you look up the proxy B and get
something from there. But why would you want to? If a label already
can stand for ONE particular proxy, then it has incorporated in its
label already everything which makes this proxy unique.

\rho


More information about the sc34wg3 mailing list