Re: [Yaml-core] Re: our information model: a typed graph

[Clark C . E. <cc...@cl...>]

On Sun, Nov 11, 2001 at 12:11:22PM +0200, Oren Ben-Kiki wrote:
| 
| As for his concern about anchors and types messing up the
| information model. I beg to differ.
| 
| Type: Perl/Python/Java/SmallTalk/Lisp/JavaScript/C++ all have at least
| *some* notion of run time type information. C doesn't, and indeed when
| loading a YAML file into C you *must* encode the type info somehow.

I'm not concerned about types.  I'm concerned about
the anchors.  Do we have a tree /w anchors or a graph?

| Anchor: Every language I know of, except perhaps /bin/sh, has a notion of a
| transient unique object id. That's typically the address of an object in
| memory. The anchor property is the same thing. Now, taking /bin/sh as an
| example of a language lacking this feature, you'd have to encode anchors
| somehow. Again it isn't optional.

This is the question:

   Are anchors accessable after a YAML object
   is loaded into memory?  

I'm not being flippiant; there is a difference between
a graph and a tree /w anchors.  In a graph, the only 
mechanism which has access to the anchors is the 
"alias" mechanism.  In this way, the anchors are 
confined to the seralization mechanism.   In a tree
/w anchors model, the anchors have much higher
visibility and you probably need to maintain 
the node's parent property.   Big difference.

| Let's not confuse people by placing the blue-sky theory
| in the spec, and bask in the warmth of our knowledge that
| this theory is available for those who seek it :-)

Please.  This is theory, but it's not "blue-sky".  It
has real life consequences on our semantics.  We have
a choice here.  Origionally we had a graph... now in
the documentation we have an anchored tree. 

Clark