From: Brian I. <briani@ActiveState.com> - 2001-05-19 16:18:47
|
I was going to put this into my reply to Oren's block syntax proposal, but I decided that's another issue altogether. BTW, I'm thinking that one over too. I'll reply later today. --- I want to propose yet another way of doing "streams" as we are now calling them. Last night, I had beers with Jeff Hobbs, a very bright guy from the Tcl community (oxymoron? ;). We didn't get into *great* detail on YAML but he had a strong suggestion on string syntax. It involved, wonder of wonders, the double quote. My proposal is adapted from that discussion. The basic idea is that you start every string with a double quote, and just keep going (regardless of line breaks) until you hit the next (unescaped) double quote. Let's try: a: "value" I know. Bear with me. b: "Another value" c: "Another value" Semantically the same as c. d: "Another value" Boggle? But it works because whitespace is insignificant in streams. So indentation is not enforced at all by the *parser*, only by the *emitter*. And this is huge because: e: "Last night, I had beers with Jeff Hobbs, a very bright guy from the Tcl community (oxymoron? ;). We didn't get into *great* detail on YAML but he had a strong suggestion on string syntax. It involved, wonder of wonders, the double quote." I just cut and pasted the above paragraph into e. It parses fine! Now we can dump huge pieces of text into YAML and (with a little escaping by hand) just let the emitter clean things up for us. f: "Last night, I had beers with Jeff Hobbs, a very bright guy from the Tcl community (oxymoron? ;). We didn't get into *great* detail on YAML but he had a strong suggestion on string syntax. It involved, wonder of wonders, the double quote." This is how the value *might* get emitted. Works fine in lists too (per Oren's new ideas on minimal lists): g: @ "value" "Another value" "Works fine in lists too (per Oren's new ideas on minimal lists):" --- Obviously we can omit the quotes on simple values. I'll let Clark come up with the escaping rules, etc. BTW, I'm not even sure we *have* to escape double quotes, unless they come at the end of a line. Just a thought. Brian -- perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf ("Just Another %s Hacker",x);}};print JAxH+Perl' |
From: Clark C . E. <cc...@cl...> - 2001-05-19 17:05:34
|
Interesting.... | e: "Last night, I had beers with Jeff Hobbs, a very bright guy from | the Tcl community (oxymoron? ;). We didn't get into *great* detail on | YAML but he had a strong suggestion on string syntax. It involved, | wonder of wonders, the double quote." | | I just cut and pasted the above paragraph into e. It parses fine! Now we | can dump huge pieces of text into YAML and (with a little escaping by | hand) just let the emitter clean things up for us. Hmm. Let me chew on this for a while. You seem to have "cut&paste" as a driving use-case. I do think that a specilized editor may be needed for us to really move forward. I see a few options: (a) We could make a simple "ed" like tool for command line junkies. (b) We could write a syntax module for scintilla, by modifying the python module. (c) We could (anyone?) write an emacs mode for YAML. I'm going to chew on this one... but I'm not sure that this use case is good enough to "break" our nice hierarchy! (which is a tenant of our markup, no?) Best, Clark |
From: Clark C . E. <cc...@cl...> - 2001-05-19 18:43:02
|
Ok. I just took a walk (to fetch more coffee) and I like your quoted string proposal Brian. Although I do think that the " character has to be escaped. I also like your proposal since it works for key values as well and this was an open item on my list. On the other hand, during the walk, I was thinking about this pathalogic case: key: this is a double spaced paragraph that cannot be folded Interstingly enough, I went through the RFC822 once more (the next day) and the behavior of this pathalogic case in an "unstructured field" is ambiguous... on one hand folding is allowed where ever there is whitespace and on the other, trailing whitespace is snipped. So, unless I have further objection, I'm going to move back to the "simpler" version of whitespace folding found in HTML and the structured fields of RFC 822. Thus, any sequence of one or more whitespace characters is folded by the parser into a single space, forcing \n, \t and \ escaping for explicit whitespace. This rule holds for "quoted strings" => "quoted strings" as well as unquoted strings. This rule is suspended for block scalars. Best, Clark |
From: Brian I. <briani@ActiveState.com> - 2001-05-19 19:28:34
|
"Clark C . Evans" wrote: > > Ok. I just took a walk (to fetch more coffee) and I like > your quoted string proposal Brian. Although I do think > that the " character has to be escaped. I also like your > proposal since it works for key values as well and this > was an open item on my list. OK. Probably a better choice to be more retrictive at this point anyway. As a note of interest, Jeff Hobbs asserted that "" was superior to \" because you could parse forward and backwards the same way. But his model did not include folded whitespace, \n, etc. I think \" is fine for our purposes. > > On the other hand, during the walk, I was thinking > about this pathalogic case: > > key: > this is a double spaced paragraph that cannot be folded > > Interstingly enough, I went through the RFC822 once > more (the next day) and the behavior of this > pathalogic case in an "unstructured field" is ambiguous... > on one hand folding is allowed where ever there is > whitespace and on the other, trailing whitespace > is snipped. > > So, unless I have further objection, I'm going > to move back to the "simpler" version of whitespace > folding found in HTML and the structured fields of > RFC 822. Thus, any sequence of one or more whitespace > characters is folded by the parser into a single space, > forcing \n, \t and \ escaping for explicit whitespace. > This rule holds for "quoted strings" => "quoted strings" > as well as unquoted strings. This rule is suspended > for block scalars. I'm in favor. I didn't really see the purpose of the intermittent non-folding rule anyways. '\ ' or '\s' is fine for this. BTW, Do we support \x05 style escaping in streams. I wouldn't mind. Might be useful. I definitely want "no escaping" for blocks. , Brian PS I feel like we're getting somewhere again. -- perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf ("Just Another %s Hacker",x);}};print JAxH+Perl' |
From: Clark C . E. <cc...@cl...> - 2001-05-19 19:39:28
|
On Sat, May 19, 2001 at 12:25:18PM -0700, Brian Ingerson wrote: | As a note of interest, Jeff Hobbs asserted that "" was superior to \" | because you could parse forward and backwards the same way. But his | model did not include folded whitespace, \n, etc. I think \" is fine for | our purposes. Yes, that is neat, but we have to worry about \n and its pals. Also, \" is familar to most programmers. | I'm in favor. I didn't really see the purpose of the intermittent | non-folding rule anyways. '\ ' or '\s' is fine for this. good deal. | | BTW, Do we support \x05 style escaping in streams. | I wouldn't mind. Might be useful. Yes, of course! | PS I feel like we are getting somewhere again. Yep. The syntax has very much taken shape unless someone finds a monkey-wrench. I'm starting to work on the specification -- and I will first post an outline and then I'll start heading for the first draft in the next 4 hours (at 8 I have mandatory, externally imposed social time... as if this isn't social... *grin*) ... On a related topic, I'd be interested in what you think about class names? Best, Clark |
From: Brian I. <briani@ActiveState.com> - 2001-05-19 19:59:35
|
"Clark C . Evans" wrote: > Yep. The syntax has very much taken shape unless > someone finds a monkey-wrench. I'm starting to > work on the specification -- and I will first post > an outline and then I'll start heading for the > first draft in the next 4 hours (at 8 I have > mandatory, externally imposed social time... > as if this isn't social... *grin*) Have fun! BTW, Post what you have each hour or so if it's no trouble. I'd like to follow along. |