From: Oren Ben-K. <or...@ri...> - 2002-01-10 11:08:34
|
Between Brian and myself. > A) The productions won't mention tabs at all. The wording > will say that > emitters *must not* emit indentation tabs and that parsers > *should* expand > indentation tabs to 8-position spaces, with warning. > > As opposed to: > > B) The Productions will allow tabs starting at 8-positions, > and not crossing > the indentation boundry. The wording will say that emitters > *must not* use > indentation tabs in any other way (not starting at an > 8-position or crossing > the boundry between indentation and content) and that parsers *should* > handle such tabs by expanding them to spaces, with warning. We agreed that (C) makes sense: C) The Productions will allow tabs not crossing the indentation boundry. The wording will say that emitters *must not* use indentation tabs which crosses this boundry. Parsers *should* handle such tabs by expanding them to spaces, with warning. But they *may* also just reject the document. As for tabs not starting on an 8-position, emitters *should* not emit such things, but they are legal (will be in the productions). > > I also would like us to have 4 scalar categories (for our public > > documentation). Simple, quoted, folded and block. These are > > sufficiently different from each other in concept. We started working on something along the following terminology: kind/structure/style/style-variant terminology : !kind branch : - !structure in-line - !style series - !style mapping - !structure multi-line - !style series - !style mapping !kind leaf : !structure in-line : - !style simple - !style quoted : - !style-variant single - !style-variant double !structure multi-line : - !style folded : - !style-variant plain - !style-variant escaped - !style block - !style-variant plain - !style-variant escaped - !style-variant chomped - !style-variant chomped escaped The leaf names are OK (other than 'structure' being somewhat lame). The branch names don't seem good (are 'series' and 'mapping' *styles*?). Maybe if we exchanged the names 'structure' and 'style'... Or something. But Brian and I agreed we had better come up with some agreed terminology for all this... Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-01-10 16:32:54
|
Clark C . Evans [mailto:cc...@cl...] wrote: > ... IMHO, tabs starting on non 8-position should also give > a warning as these should be rare unless someone is > mixing tabs and spaces... Take it up with Brian... he has some justification going for it (users using a dumb editor, not seeing the fact that spaces and tabs are mixed). > Two more items: > > - I'd rather not have chomped folded scalars, > no-ops like that should be syntax errors. For what its worth I agree. I don't feel that strongly about it. Take it up with Brian :-) > - It would be nice to use "\" for escaped > without having to put in "^\". Hmmm. That's a bit of a special case... Also it would make \ an indicator again. Currently we can make due with ^ and | being indicators and allowing \ to be a normal content character (just like - is). We may want it for some implicit type... > | We started working on something along the following terminology: > | kind/structure/style/style-variant > | > | terminology : > | !kind branch : > | - !structure in-line > | - !style series > | - !style mapping > | - !structure multi-line > | - !style series > | - !style mapping > | !kind leaf : > | !structure in-line : > | - !style simple > | - !style quoted : > | - !style-variant single > | - !style-variant double > | !structure multi-line : > | - !style folded : > | - !style-variant plain > | - !style-variant escaped > | - !style block > | - !style-variant plain > | - !style-variant escaped > | - !style-variant chomped > | - !style-variant chomped escaped > > Ok. I was thinking of calling these "Syntax Kinds" and > defining them via a few switches (properties). This is > primarly for the "C" API, which bit-fields are common. > Quite clearly there are combinations which don't make > sense; but this is normal for bit-fields. OK... But that's just an implementation trick. The "true" description is a tree. Either way we need names for things to be able to talk about them in the spec. Do you feel comfortable with "style" being used to describe the property which can be series/mapping for a branch and simple/quoted/folded/block for a leaf? I'm not quite comfortable with calling both with the same name. Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2002-01-10 18:01:18
|
On 10/01/02 18:33 +0200, Oren Ben-Kiki wrote: > Clark C . Evans [mailto:cc...@cl...] wrote: > > ... IMHO, tabs starting on non 8-position should also give > > a warning as these should be rare unless someone is > > mixing tabs and spaces... > > Take it up with Brian... he has some justification going for it (users using > a dumb editor, not seeing the fact that spaces and tabs are mixed). Right. I pushed hard for no warning here. It's too subtle for humans. And it's an arbitrary rule. There is no conflict with mixing tabs and spaces. All editors handle this fine. We should too. > > > Two more items: > > > > - I'd rather not have chomped folded scalars, > > no-ops like that should be syntax errors. > > For what its worth I agree. I don't feel that strongly about it. Take it up > with Brian :-) If that's the case then let's accept '|\-', make '|-\' an error, and be done with it. Either choose flexible or rigid, not in between. In Perl, the chomp() command removes the final newline, *if* it exists. Otherwise it's a no-op! That's why mixing-and-matching works for me. > > > - It would be nice to use "\" for escaped > > without having to put in "^\". > > Hmmm. That's a bit of a special case... Also it would make \ an indicator > again. Currently we can make due with ^ and | being indicators and allowing > \ to be a normal content character (just like - is). We may want it for > some implicit type... No way Clark. Skip the shortcuts. Too much to explain. And also what Oren said. Now, if you don't like '^', that's a different story. Feel free to pick a different one. You know, we can even pick '\', because in '\\', the first backslash is the indicator, the second one is the modifier. I rather like the old look, with the new syntax. OTOH, I like '-' over '|' for chomp, considering the new syntax. > > > | We started working on something along the following terminology: > > | kind/structure/style/style-variant > > | > > | terminology : > > | !kind branch : > > | - !structure in-line > > | - !style series > > | - !style mapping > > | - !structure multi-line > > | - !style series > > | - !style mapping > > | !kind leaf : > > | !structure in-line : > > | - !style simple > > | - !style quoted : > > | - !style-variant single > > | - !style-variant double > > | !structure multi-line : > > | - !style folded : > > | - !style-variant plain > > | - !style-variant escaped > > | - !style block > > | - !style-variant plain > > | - !style-variant escaped > > | - !style-variant chomped > > | - !style-variant chomped escaped > > > > Ok. I was thinking of calling these "Syntax Kinds" and > > defining them via a few switches (properties). This is > > primarly for the "C" API, which bit-fields are common. > > Quite clearly there are combinations which don't make > > sense; but this is normal for bit-fields. > > OK... But that's just an implementation trick. The "true" description is a > tree. Either way we need names for things to be able to talk about them in > the spec. Do you feel comfortable with "style" being used to describe the > property which can be series/mapping for a branch and > simple/quoted/folded/block for a leaf? I'm not quite comfortable with > calling both with the same name. What about "branch style" and "leaf style"? Picking new words for every distinction is more confusing than overloading well chosen words. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-01-10 18:57:38
|
| > > ... IMHO, tabs starting on non 8-position should also give | > > a warning as these should be rare unless someone is | > > mixing tabs and spaces... | > | > Take it up with Brian... he has some justification going for it | | Right. I pushed hard for no warning here. It's too subtle Ok. | > > - I'd rather not have chomped folded scalars, | > > no-ops like that should be syntax errors. | > | > For what its worth I agree. I don't feel that strongly about it. Take it up | > with Brian :-) | | If that's the case then let's accept '|\-', make '|-\' an error, and be done | with it. Either choose flexible or rigid, not in between. Ok. | > | > > - It would be nice to use "\" for escaped | > > without having to put in "^\". | > | > Hmmm. That's a bit of a special case... | | No way Clark. Skip the shortcuts. Too much to explain. Ok. ;) Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Clark C . E. <cc...@cl...> - 2002-01-10 14:50:48
|
| C) The Productions will allow tabs not crossing | the indentation boundry. The wording will say that emitters | *must not* use indentation tabs which crosses this boundry. | Parsers *should* handle such tabs by expanding them to spaces, | with warning. But they *may* also just reject the document. | As for tabs not starting on an 8-position, emitters *should* | not emit such things, but they are legal (will be in the | productions). Ok. IMHO, tabs starting on non 8-position should also give a warning as these should be rare unless someone is mixing tabs and spaces... Two more items: - I'd rather not have chomped folded scalars, no-ops like that should be syntax errors. - It would be nice to use "\" for escaped without having to put in "^\". | We started working on something along the following terminology: | kind/structure/style/style-variant | | terminology : | !kind branch : | - !structure in-line | - !style series | - !style mapping | - !structure multi-line | - !style series | - !style mapping | !kind leaf : | !structure in-line : | - !style simple | - !style quoted : | - !style-variant single | - !style-variant double | !structure multi-line : | - !style folded : | - !style-variant plain | - !style-variant escaped | - !style block | - !style-variant plain | - !style-variant escaped | - !style-variant chomped | - !style-variant chomped escaped Ok. I was thinking of calling these "Syntax Kinds" and defining them via a few switches (properties). This is primarly for the "C" API, which bit-fields are common. Quite clearly there are combinations which don't make sense; but this is normal for bit-fields. The advantage of this for the API level is that each property (like escaping) can be checked independently. (0/1) - alias - branch (collection) - multi-line - folded - escaped - chomped - single-quoted - sequence ABMFECSQ 00000000 Plain in-line scalar (could be implicitly typed) 00000010 Single quoted in-line scalar 00001000 Double quoted in-line scalar 00100000 Block scalar 00100100 Block scalar (chomped) 00101000 Block scalar (escaped) 00101100 Block scalar (escaped+chomped) 00110000 Folded scalar 00111000 Folded scalar (escaped) 01000000 In-line mapping 01000001 In-line sequence 01100000 Multi-line mapping 01100001 Multi-line sequence 10000000 Alias node Note that in the graph model alias nodes are resolved, and in the tree/graph model only the first distinction (branch/eaf) or (collection/scalar) is significant. This fits nicely into an 8-bit field, and of cource accessors "isEscaped()" could be given that checked the field. Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |