[sc34wg3] Possible TMRM issue

Robert Barta rho at bigpond.net.au
Tue Mar 21 04:08:01 EST 2006


On Sat, Mar 18, 2006 at 04:59:30PM +0100, Lars Marius Garshol wrote:
> TMRM instances are sets of proxies, which implies that you can't have  
> duplicate proxies. Proxies, in turn, are sets of (proxy, proxy)  
> pairs, which gives you a simple, but recursive structure.

Larsbot,

The structure you describe is not the one on which we settled in TMRM
(see below). What you describe was in some versions of Tau+ as an
attempt to simplify the formalism (and hence the explanation
effort). But as you correctly point out....

> How is it possible to efficiently detect duplicates in this model?
> In theory you may have to traverse the entire model every time you
> want to compare two proxies.

...such a recursive data structure comes with a potential high price
if implemented verbatim. But OTOH, no specification of a declarative
language is then implemented verbatim.

Anyway, we gave up this 'simplification' because all the formalism
which is based on the proxy structure would potentially have to cope
with infinite data structures. And that can be tricky, mathematically,
without giving us any benefits.

--

Instead, we fell back to what we originally had in the earliest
incarnation of the model: labels (aka 'internal identifiers) which are
magically glued to proxies (entanglement :-). They are like
fingerprints (I actually use MD5 over the proxy content here). So the
current model differs from what you describe above:

  - a map is a set of proxies

  - proxies are sets of properties

  - properties are key (= always label) / value pairs

  - values can be integer, string, guinea-pigs, whatever, or they can be labels

The only 'annoyance' is that in the formalism built on top of the
above, we have always to provide a lookup between the mentioning of a
label (get its proxy), or the other way round. Here we sloppily say

 "Labels for proxies and proxies so labeled are used interchangeably."
 [ Typical Patrick-speak :-]

\rho


More information about the sc34wg3 mailing list