Expressions in attribute offset addresses

Many action expressions designate a note, either by name, by path, or by object designators such as parent or prevSibling.

An extension to the path mechanism allows you to replace the normal string literal used for note designation with an expression:

$Color(7*6); ← the colour of the note named "42"

$Color($Path); ← the colour of the note whose name is stored in the attribute "Path"

In the case of ambiguity, expression evaluation has the lowest precedence. For example, if a note happens to be named "7*6", the reference will be resolved to that note, not to the note named "42".

In actions, offset addresses in which the inner values is an expression are now supported. For example, where variable 'vMagicKey' holds he name of a dictionary key:

$MyString = $Name(nextSibling($MyDictionary[vMagicKey]))

The way nested designator expressions are handled might conceivably change the behaviour of previously-working code. A good refactoring is to unpack the nesting. Thus instead of:

$Result = $Name(nextSibling(fComplexFunction($MyString))); 

consider:

	var:string vPath=fComplexFunction($MyString); 
	$Result=$Name(vPath);