DTS language enhancements

[David Gibson]

On Tue, Oct 07, 2008 at 11:50:38AM -0500, Scott Wood wrote:
> On Tue, Oct 07, 2008 at 12:41:03PM +1100, David Gibson wrote:
> > > Instead of /addnode/, how about an alternate version of (or option to)
> > > /merge/ that merges the second tree with the contents of the first,
> > 
> > Um.. I don't entirely see how this variant of /merge/ would differ
> > from /addnode/.
> 
> /addnode/ can only add one node at a time, and has an different syntax
> than normal for representing the node to be added (name is split from
> body).  /mergeunder/ could add any number of nodes and/or properties,
> and would use more normal syntax.

Um.. in that case I don't see how this differs from the original
/merge/.

> > > rather than treating the trees as sharing a root?  This could also
> > > supersede /setprop/, if conflicts are defined to be resolved in favor of
> > > the second tree.
> > 
> > True, and I was assuming /merge/ would resolve conflicts in favour of
> > one of the trees.  As I said, these suggestions are only an outline -
> > I'm not entirely sure what we need by way of node expressions.
> 
> Understood -- I was just trying to help refine the suggestion.  I think
> the ideal way forward involves elements of both your proposal and Jon's.
> 
> > > > It's possible to do this just with the /setprop/, /addnode/ operators
> > > > described above, but that's awkward and verbose, so allowing
> > > > expressions in the same place the property/node names go now seems
> > > > better.  jdl's patch series allows this, but I'm not sure what makes
> > > > the grammatical distinction between the parser expecting a bare node
> > > > name and an expression, which worries me.
> > > 
> > > I think it's the leading backslash before identifiers that distinguishes
> > > it.
> > 
> > Uh.. this doesn't make sense, an expression doesn't have to contain
> > identifiers (constant expressions).
> 
> It's not nonsensical, just incomplete -- I was assuming that it was
> obvious that quote-marks differentiate string constants.  Integer
> constants would need parentheses in that context, though.

Yeah, and having the grammatically distinguishing difference spread
across the pieces, or (potentially) buried deep inside the expression
is not sensible, either from a parser design or readability point of
view.  Much better to wrap the whole thing in parens.

> > Actually I suspect it's the presence of quotes which does the trick,
> > at least in the examples Jon's given.
> > 
> > > > What I would suggest here is that expressions for node/property names
> > > > must be parenthesized.  ( and ) aren't used in node/property names
> > > > either in theory or practice AFAIK and this is consistent with integer
> > > > expressions having to be parenthesized within cell lists to avoid
> > > > ambiguity.
> > > 
> > > I'd rather have an identifier prefix than to require parentheses in
> > > otherwise unambiguous contexts (which would basically amount to needing
> > > both a prefix and a suffix).  This applies to cell context as well.
> > 
> > As above, this doesn't work.  It doubly doesn't work for cell context,
> > because we need to disambiguate <3 (-2)> (2 cells) from <(3-2)> (1 cell).
> 
> It was a bare identifier (or function call) that I had in mind as a
> non-ambiguous context, though I can see how allowing that might
> complicate the implementation a little -- and allowing things like 3*2
> to be unparenthesized would be even more complex.

Again, I think we should make things non-ambiguous by design, rather
than by allowing any non ambiguous form, even if it requires parsing
deep into the thing to resolve the ambiguity.  Doing otherwise both
complexifies the implementation and threatens readability

> We probably should have added comma-delimiting when we switched to
> decimal-by-default.

Maybe, but its done now.  I really don't think requiring parens aroud
expressions is that big an imposition.

> > Ah, yes, this is something I had a plan for, way back.  I wanted to
> > keep the [...] construct as a being a very compact representation of
> > bytestrings - bytestring literals effectively.  That means bare hex
> > and no expressions (because expressions and bare hex are a highly
> > confusing mix as we've discovered).  But, I was intending to extend
> > the celllist construct to allow the "cells" to be of different sizes -
> > this would be useful for dealing with 64-bit quantities too.  Not sure
> > how to do the syntax, though  Possibly:
> > 	<.1 0xab 0xcd > 		(1 byte entries)
> > 	<.8 0xdeadbeef00000000 >	(8 byte entries)
> > Defaulting to .4, of course.  I'm not over fond of that though.
> > Better suggestions welcome.
> 
> Seems reasonable.
> 
> -Scott
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson