Hmmm. Sound interesting.

Does that mean it would be possible to relax the restriction that aliases only point back? After all, if they are loaded to a "reference", and one only de-references it after loading the whole structure, this should be possible (though it would destroy the assumption of a single-pass-de/serialization process). Perhaps such references would use a different notation (**foo = point to foo anywhere in the document, as opposed to *foo = point to a foo that was already defined).

Another, related intriguing option is to allow references by path instead of by anchor. It is extremely useful to be able to say (for example) foo: @bar.baz to refer to { bar: { baz: this_value } }. This doesn't work well when one considers "aliases", but very well when one considers "references". And this case obviously points to arbitrary position, either before or after the reference point.

Definitely worth investigating further...


On Mon, Nov 5, 2012 at 7:37 AM, Ingy dot Net <> wrote:

I had an idea today. It probably would apply to YAML2 more than YAML. I just wanted to throw it out there, and see if people can shoot it down.

The idea is to turn aliases into plain scalars, and the normal convention would be to load them as references to anchors. So things work as before under normal dump/load.

Thus * is no longer a special syntax char and can start any plain scalar.

This might be extended as the normal way to do other kinds of fancy impliciting like file includes:

content: *include file.yaml

Whether it gets used in new ways or not, I just think that *foo can be parsed as an implicit scalar. Can people see holes in that logic?


LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
Yaml-core mailing list