Re: ns-l+block-node vs. s-l+block node in working draft

On Wed, May 21, 2008 at 2:42 PM, Burt Harris <[email protected]> wrote:
> In Working Draft 2008-05-11, production 208 references ns-l+block-node,
> which isn't defined.   Instead production 197 defines s-l+block-node which I
> think might be what's intended.   I'm not sure what the correct name is, but
> it looks like a typo in one place or the other.

Yes, it is a typo. Nice catch! I have a Perl script that verifies some
of the productions against typos, but it doesn't catch the case where
there are explicit non-default parameters. I'll fix this problem and
look into enhancing the script.

> Also regarding the production naming, I'd suggest it might make sense to
> distinguish between simple character-class productions (with a c- prefix),
> from the more complex indicator-based productions (with perhaps a i-
> prefix).

Hmmm... In principle you have the same issue with distinguishing
between single character and complex productions in general - e.g.,
b-char and b-break.
One way to do it would be to say x-x-name for complex productions,
instead of collapsing their name to x-name - so it would be b-char but
b-b-break.
I'm not certain this is more readable though...

> I'm not sure what motivated the change from V1.1's  c-l-block-sequence to
> V1.2's l-block-sequence; whatever the reason, I applaud it!

It just sort of worked out better that way. I tried hard to simplify
the productions... not that the result is "simple" by any means ;-)

> I think
> reducing the number of productions that start with a comment or non-indent
> whitespace will make it much easier to map the spec. to practical
> implementations.   Perhaps some simpler Hungarian prefix for block
> constructs like s-l+block-indented would help.  I'm not sure how to put this
> in parser terminology, but after having struggled with 1.1s productions for
> quite a while, it seems like a good idea.

I'm open to suggestions for a better notation!

BTW, I established the current one when I was struggling to keep track
of things myself - and I was _writing_ the productions at the time. I
appreciate how much harder it is to read them without having them "in
your head" first.

> It would be incredibly useful to
> be able to express YAML's syntax with the same sort of railroad track
> diagrams that JSONs is documented in.

I considered that, but there are several problems with it:
- It would make the spec even longer. A one-line production can easily
become a multi-line diagram.
- There's no program I know of that automatically generates these
diagrams. I'd have to write one myself or something. I suspect the
JSON ones were done by hand.
- I'm not certain this would improve readability by that much. I feel
the complexity doesn't stem from single complicated productions, but
by the amount of them. If there are specific productions that you feel
are too complex, I could split them up... I don't _think_ there are
productions I can easily merge, but if you can think of any, let me
know!

Thanks!

    Oren Ben-Kiki

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/