Re: example 7.17 in YAML 1.2 spec 2009-07-21

On Thu, 2009-10-01 at 09:02 +0900, Osamu TAKEUCHI wrote:
> Your definition does not seem to increase readability.
> Let me show some examples...

I'm fine with them. IMO interpreting a::::: as either "a::::": or
"a:::::" is hard to understand. Some people will "obviously" see it as
one, some will "obviously" see it as the other, both groups with the
same level of conviction. That's not readable; a readable construct has
only one "obvious" interpretation. And readability is our #1 goal.

> The idea is that ':' is treated as part of the plain text
> unless it is followed by a delimiter in the context, which
> includes a space and a line break.

You make a good case and I can see how this would seem consistent on its
own. But - I feel it is inconsistent with the spirit of other YAML
indicator rules. In general we tend to interpret indicators as
indicators by default, unless there's some good reason not to - as
opposed to the other way around. E.g., we decided to disallow the
oh-so-attractive 1,000,000.00 format for numbers - we always treat an
unquoted ',' as a separator. The winning argument there was again
"unsurprising" readability: what does {1,234} mean?

> In addition, we have to look ahead
> only one character. Your rule requires to look ahead many 
> characters.
> 
> {a:::::::::::b}   =>   { "a:::::::::::b" : null }
> {a::::::::::::}   =>   error

True, but since we have a limited 1K lookahead in such cases anyway,
this is not really an issue. Especially since trailing ':' characters
are a rare use case (embedded ':' and prefix ':' are much more common -
URLs, C++ namespaces, etc.). We never hesitated to sacrifice parser
complexity for gaining readability (the plain scalar is hellish to
parse, we know).

Finally, there's also the question of giving ourself a way to back out
of bad decisions (which you may feel this one to be :-). I'd much rather
play it safe and make trailing ':' characters an error for now. If this
turns out to be a mistake, it is easy to change the rules to allow them,
while maintaining compatibility with all existing files. If on the other
hand we start allowing them now, then decide this was a mistake, it
would be harder to switch back - as this would break once-valid files.

Have fun,

    Oren Ben-Kiki


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf