From: Oren Ben-K. <or...@ri...> - 2001-12-16 17:29:12
|
Clark C . Evans [mailto:cc...@cl...] wrote: > The last use case has shown me the value of allowing > a map with a single pair entry to be included on > the same line. :-) > However, it has also shown to > me that two or more pairs should not be allowed > to use this short cut. Hmm... Nice catch. Took me a while to figure it out, which is saying something :-) > I really don't like that a single > space can completely mean a different > structure... too magical. This irks me. > So. I say we allow 0 and 1, but we > forbid 2 and 3. Number 4 should be > allowed, although I think we may > want to enable a single space in > this case, rather than two. It is a whole different ball game if you are willing to play with the nesting level rules. Let's see for a second what happens if you don't: # nested --- - in-line: value - another: [ 1, 2 ] - mapping: key: value - folded: \ value - ? \ folded key : case # in-line --- - in-line: value - another: [ 1, 2 ] - mapping: key: value - folded: \ value - ? \ folded key : case I think we all agree this is too confusing to allow. Assuming we are willing to play with the nesting rules, we have two options: - Restrict the in-line form to a single pair and indent *its value* one extra space. - in-line: value - another: [ 1, 2 ] - mapping: key: value - folded: \ value - ? \ folded key : case - Allow everything in the in-line form and further indent all *pairs* by one space. - in-line: value - another: [ 1, 2 ] - mapping: key: value - folded: \ value - ? \ folded key : case - multiple: pairs in-line: value another: [ 1, 2 ] folded: \ value mapping: key: value I think it is obvious that *if* you want to play with nesting this is the way to go: it is identical for the simple cases but also allows for the general ones. There's simply no point in restricting it to a single pair in this case. So, the way I see it, our options are: - Drop it: Dropping it is the simplest option :-) We would have to fix a bug in production 105: /* The 'n' was missing from single_keyed */ in_series_keyed(n) ::= single_keyed(n) nested_keyed(n)? - Restrict it to a single pair with *in-line* (leaf or branch) key and value; This would mean re-writing production 105 as follows: in_series_keyed(n) ::= in_line_node line_space* keyed_entry_separator in_line_node - so only this: is legal - [ and, that ] : { of: course } - Nest all pairs with one additional space as above. This means a four character change to the (fixed) production: in_series_keyed(n) ::= single_keyed(n+1) nested_keyed(n+1)? This would allow everything to be used (as shown above). As you can see, all of them are pretty simple solutions... Restricting it is far less magical but further nesting much more useful (list of untyped mappings would be a common idiom, right?). My order of preference would be: - Further nest pairs; - Restrict to in-line key and value; - Drop it. But I could live with any of the three choices. Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-12-16 19:51:06
|
| > However, it has also shown to me that two or more pairs | > should not be allowed to use this short cut. | | Hmm... Nice catch. Took me a while to figure it out, which is saying | something :-) ... | - Further nest pairs; | - Restrict to in-line key and value; | - Drop it. It's just too confusing for me. I say drop it. Clark |