node reference: path from a label

[John Bonesio]

Hi,

I was talking to Grant Likely a bit about the path from a label syntax,
and we came to what we thought was a good solution. I was supposed to
propose it with another patch submission, but now I'm rethinking this. I
thought I'd go into detail on the problem so we might all work together
to come to a good solution.

My concern here is we'll end up doing what happened with the Perl
language. In Perl they started out with a good functional scripting
language, but then later adopted an object oriented approach along with
other new features. Eventually it got to where certain syntax didn't
work with other syntax. It is legal syntax, but doesn't produce the
expected results, because the combination could have multiple meanings.
In my opinion, the design of that language is now broken, and in face a
newer version of this language is being worked on which will break
backward compatibility with existing code (even the developers recognize
the problem).

A part of our problem is that we are trying to make a syntax for 'path
from a label' in the context of an undefined syntax for 'path from an
alias'. It makes discussion of 'path from a label' difficult because I'm
trying to fit it in with a 'path from an alias' syntax that is in
people's heads.

I think we need to talk about how we might implement path from an alias
so that we can talk concretely about whole concept of how we want to
specify references to nodes.

(Syntax #1)
When Grant and I chatted, we can come to the following:
	& - means reference

	&{&label/path/from/label}
	&{alias/path/from/alias}  (future syntax)
	&{/path/to/node}
	&label
	&{alias}
	&{/}


As I thought about it, the problem with this is that the syntax requires
differing contexts to resolve what '&' means.

We have &{&label/path/from/label} to mean reference the labeled node
first, then resolve the rest of the path reference from there (sort of a
nested referencing).

So then what do we do with the alias? We stared with
&{alias/path/from/alias}. But then in the syntax it doesn't look like
we're referencing the alias node like we would for the label node, we're
just sticking the alias name in there. So the label and the alias don't
appear to be treated the same.

Perhaps we could add a different character to mean reference to an
alias, perhaps %alias. 
(Syntax #1a)
So we use
	&{%alias/path/from/alias}.

With this approach we have 3 syntaxes to specify a refernce;
	&label - reference to label
	%alias - reference to an alias.
	&{/path/to/node}
	&{&label/path/to/node}
	&{%alias/path/to/node}

It could work, but we have multiple syntaxes to reference nodes
depending on if by label or alias. Or depending on how you look at it,
we have '&' meaning label identifier or reference to node depending.

Some of the other suggestions:

(Syntax #2)
As David Gibson suggested we could have:
&label{/path/from/label}
or
&label{path/from/label}

Both of these still begs the question of what we do with the path from
an alias. Do we use the following?
	&{alias/path/from/alias}

To the casual observer, they probably will be wondering why the label is
treated so differently from the alias when conceptually they're so
similar? I might also be hard to for dts writers to remember which
syntax to use for the label vs the alias.

(Syntax #3)
Another syntax was proposed:
	&label {
		    path/to/subnode {
		            new-property;
		    };
	};

So what would do to reference from an alias?
	&{alias/path/from/alias}
	
Again we end up with very different methods to do very similar things
depending on if the start of the reference is an alias or a label.

(Syntax #4 - My actual proposal here)
For this syntax (below) to work, we need to set up some semantics first.
The first rule is this:
Every alias defined in the dts file also defines a label with the same
name on the aliased node.

>From tests/aliases.dts:
/ {
        aliases {
                s1 = &sub1;
                ss1 = &subsub1;
                sss1 = &subsubsub1;
        };

        sub1: subnode at 1 {
                compatible = "subnode1";

                subsub1: subsubnode {
                        compatible = "subsubnode1", "subsubnode";

                        subsubsub1: subsubsubnode {
                                compatible = "subsubsubnode1",
"subsubsubnode";
                        };
                };
        };
};

In the above example, /subnode at 1 ends up having labels: &sub1 and &s1.
The aliases nodes still exist in the tree for referencing at run time.

If desired, aliases can re-use label names. For example the following is
valid:

	aliases {
                sub1 = &sub1;
        };

In this case, an alias node is created for 'sub1', and the label on
subnode at 1 is just &sub1.

With these semantics, then we only need a syntax for the following:
	* reference by label
	* reference by path
	* reference a path from a label (also covers path from an alias)

And we can use the following syntax:
	&label (syntactic shortcut for &{label})
	&{label}
	&{/path/to/a/node}
	&{label/path/from/label}

With this '&' always means reference, and a reference to a path from an
alias is built in by the semantics.

For this, we will probably want to go ahead and implement the label
semantics on an alias to make sure we don't forget all this and do
something unintended. Or we can just document it somewhere where we're
sure to see it.

(Syntax #5)
I think other options would have to include deprecating some or all of
the current syntax. This might include deprecating
	&{/path/to/node}
	
So that we can make '&label' always be just a label identifier and then
have something else to mean reference (maybe '%'). Then we'd have to
have something else that means alias identifier (maybe '$'). This would
produce something like
	%{&label}
	%{/path/to/node}
	%{&label/path/to/node}
	%{$alias/path/to/node}

I haven't had much time to work through the details on this one, and
there might be other options for what syntax we keep and what we
deprecate.

Thoughts?