The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Friday, August 31, 2012

Brackets - XML, and non

I like XML's "brackets":  <longname attributes="attributes"> ... </longname>.

Makes XML much less vulnerable to mismatches like dropping a paren:

<A> <B> <C> <D> ... </D> </B> </A> - the missing &lt/C> can be inferred, and possibly even repaired

(A: (B: (C: (D: .... ) ) )
which closing paren is missing? A, B, C, or D's?

But... sometimes I end up editing XML by hand. (Like on a wiki. (Or in blogger :-( )  And sometimes typing <longname>...</longname> is just too much.

Sometimes I would like the option of having a more compact, but less robust, bracket notation. Like the above mentioned (A: ... )

Or [A: ... ].  Or {B: ...}.  Or (although that latter is hard to tell from XML.)


<A> (B: {C: [D: ... ] ) </A>

it is still pretty easier to infer that the closing } for {C:  is missing.

Here's a thought: the matchingness of brackets is orthogonal to the actual name of the construct that uses the bracket - in XML parlance, the element.

LISP dialects that use only parens ( and ) exclusively are at one end of the spectrum.

XML, with arbitrary <tag> ... </tag> is at the other end.

And in between, we can have notations that use matching { and }, [ and ], < and >, << and >> - heck, Perl and regexps show that there don't even need to be matching pairs.  ' and '. " and ". Or ‘ and ’, etc.

These could be intermixed, as I have done before.

Indeed, the same entity, the same statement type, could use either bracketing form: &ltA> (A: ... ) </A>

I can imagine tools that translate between these forms.

From XML: &ltA> <A> ... </A> </A>

To strictly lisp-like parens: (A: (A: ... ) )

To forms that employ multiple bracket types for "clarity": (A: {A: ... } )


I guess that I am using (A: ...) as the compact representation of <A>...</A>.

Q: what about attributes? (A at1="at1" at2="at2" ... : ...)


There seems to be little lossage here. Except for the lost opportunity to place attributes on closing XML tags, <tag attributes>...</A closing-attributes> --- something that XML does not allow, but which I have supported in my own pseudo-XML dialects.