From: Oren Ben-K. <or...@ri...> - 2002-04-10 06:21:04
|
Clark C . Evans [mailto:cc...@cl...] wrote: > --ArbitrarySeparators should have been removed from the specification > as a part of the flexible indentation patches. We had --Arbitrary > when we had a strict one space per indentaion level rule. With that > rule we needed a way to allow content having -- in column zero. This > hack was borrowed from MIME and accomplishes this. Fortunately, since > we now have flexible indentation it can go away! I'm not certain I agree. Today's rules allow me to take: --- | file 1, doc 1 --- | file 1, doc 2 And --- | file 2, doc 1 --- | file 2, doc 2 And using simple concatenation create the following: ---FILE | --- | file 1, doc 1 --- | file 1, doc 2 ---FILE | --- | file 2, doc 1 --- | file 2, doc 2 That is, we can convert any YAML file to a block just by prefixing it with a header line. I think this is pretty useful. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-04-10 07:59:44
|
Neil Watkiss [mailto:neilw@ActiveState.com] wrote: > > ---FILE | > > --- | > > file 1, doc 1 > > --- | > > file 1, doc 2 > > ---FILE | > > --- | > > file 2, doc 1 > > --- | > > file 2, doc 2 > > Eek! > > The way _I_ read it, by today's rules, that's an empty block, > then a parse > error on line 2, because you don't have the same document > separator. That's > also the way YAML.pm reads it. I suppose we could be wrong... Well, the current spec doesn't forbid having lines starting with '---' inside a non-indented top-level block - at least the way I read it. Obviously this needs explicit clarification in the spec. So the question isn't "what does the spec say", it is "what do we *want* it to say". > Besides, don't you think that looks really ugly? We can go > further and end up > with YAML that no one could possibly edit, which is against > our primary goal. I was thinking about how easy it is to "encapsulate" YAML nodes/documents/streams as text blocks inside a YAML structure with minimal work. Brian is fond of showing this: node: - some YAML stuff Becoming: node: | - some YAML stuff That is, how with the addition of one character you can "quote" a whole chunk of YAML. I think that allowing the same sort of operation in the document/stream level is useful. Yes, it isn't very readable, unless you use some sensible separator scheme, e.g.: ---STREAM | ---DOC ... ---DOC ... ---STREAM | ---DOC ... ---DOC ... > The method of converting things to blocks should be adding a block > indicator and indenting by one space. Otherwise lazy programmers like > you and I will overpower the poor humans who have to read our trail of > incomprehensible YAML. The difference is that above example are *not* of nested blocks. For example, the STREAM/DOC example is of a single stream containing exactly two documents. It so happens that each document contains text which is a valid YAML stream. The YAML parser given this example should *not* parse these texts as a YAML streams, however! For it they are just simple chunks of text. > And indenting by one space isn't a huge chore, is it? > > ycat file1 file2 > > `ycat' is a very simple program which emits this YAML stream: Writing: { echo '---SEPARATOR |'; cat file1; echo '---SEPARATOR |'; cat file2 } Doesn't require *any* program. > As a final motivator, think of the cool slogan: > > "Why cat, when you can ycat?" It better the other way around :-) Have fun, Oren Ben-Kiki |
From: Neil W. <neilw@ActiveState.com> - 2002-04-10 08:10:53
|
Oren Ben-Kiki [10/04/02 04:01 -0400]: > > The way _I_ read it, by today's rules, that's an empty block, then a > > parse error on line 2, because you don't have the same document > > separator. That's also the way YAML.pm reads it. I suppose we could > > be wrong... > > Well, the current spec doesn't forbid having lines starting with '---' > inside a non-indented top-level block - at least the way I read it. > Obviously this needs explicit clarification in the spec. So the question > isn't "what does the spec say", it is "what do we *want* it to say". Okay. [...] > > And indenting by one space isn't a huge chore, is it? > > > > ycat file1 file2 > > > > `ycat' is a very simple program which emits this YAML stream: > > Writing: > > { echo '---SEPARATOR |'; cat file1; echo '---SEPARATOR |'; cat file2 } > > Doesn't require *any* program. I disagree -- you have to grep through file1 and file2 to make sure your separator is unique. So you'll need a program: a _small_ program, but a program none the less. Frankly, I see nothing wrong with your idea. It's very simple for the parser to restrict document separators to "the one I've already seen", except for the first document, or an implicit first document (which pretends it's seen "---"). My argument is that I don't want to _read_ documents like that. Maybe it's okay: my use case (configuration files) is not yours (concatenating YAML streams). > > As a final motivator, think of the cool slogan: > > > > "Why cat, when you can ycat?" > > It better the other way around :-) Phooey! "Why ycat, when you can cat?" Why didn't I think of that? Later, Neil |
From: Oren Ben-K. <or...@ri...> - 2002-04-11 13:34:31
|
Neil Watkiss [mailto:neilw@ActiveState.com] wrote: > > | # note: no first separator. > > | foo: bar > > | --A-Separator #YAML:1.0 > > | baz: com > > > > According to the current spec, this is illegal, but > > not in the way you may think. Its illegal beacuse > > the map key "--A-Separator #YAML" is lacking quotes. > > Aha! Wrong. The `inline_keyed_entry' production requires at > least one space > between `keyed_entry_separator' and `inline_node', and there > is no space > before '1.0' in this example. So the only possible match for > `#YAML:1.0' is > as a document directive. Otherwise, the following becomes ambiguous: You are right. The example above is still an error, however... because there's no 'keyed_entry_separator' in the line and there should have been one there :-) The '--A-Separator' is not taken to be a separator because it the separator is implicitly assumed to be '---'. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-04-11 13:34:49
|
Clark C . Evans [mailto:cc...@cl...] wrote: > | That is, we can convert any YAML file to a block just by > | prefixing it with a > | header line. I think this is pretty useful. > > I can't think of one use case where I'd need that ability > and where indenting the two files would not be adequate. I thought of something like packing several text files into a single stream, even if said text files happen to contain YAML text - as part of a messaging system, YAR, or whatever. Being able to do this without indentation means that it is possible to just interleave YAML header data and file data, without going "into" the files themselves. > As for stream concatination, 99% of the use cases here will > be merging log files / transaction journals. And in this > case conversion to block is not part of the operation. Right. Concatenating YAML streams into a single stream may be more common and has little bearing on the issue. > Now, I do see the use case to include an entire YAML block > or text files having -- as a map or seq value. However, > the prefix hack doesn't help you here as it only applies > at the document level. Yes. If you want the file's content to be included in a nested leaf, you have to indent it (since our in-line form doesn't allow multi-line variants). > I claim that this isn't a useful feature beacuse it seems to > be only useful in the cross product of two uncommon requirements: > (a) converting a free-standing file into a *document* and not > a leaf value, and (b) concatinating a stream of arbitrary files > to get a sequence of YAML documents, each document with only > one block. I agree these are the use cases. Their usefulness is the issue... > The whole reason for the --Unique block MIME hack was so > that we could have top level scalars including "--" in column > one. Before our flexible indenting we needed this hack... > now with flexible indenting we don't. The cost vs benifit > just isn't there, it is a high cost feature and the return > on our investment is very little. To this effect, I had > actually removed this feature from my "mental copy" of > the YAML spec several months ago. Hmmm. Like I said, if both you and Brian feel this way, I'll go with it... Brian? Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2002-04-11 20:17:20
|
On 11/04/02 04:50 -0400, Oren Ben-Kiki wrote: > Hmmm. Like I said, if both you and Brian feel this way, I'll go with it... > Brian? I think both arguments are compelling. So let's move on to another YAML design goal: easy to implement. I think the single '---' is easiest to implement. And it's better to be strict up front and lenient later if the public demands it. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-04-12 02:16:12
|
On Thu, Apr 11, 2002 at 01:17:10PM -0700, Brian Ingerson wrote: | On 11/04/02 04:50 -0400, Oren Ben-Kiki wrote: | > Hmmm. Like I said, if both you and Brian feel this way, I'll go with it... | > Brian? | | I think both arguments are compelling. So let's move on to another YAML | design goal: easy to implement. | | I think the single '---' is easiest to implement. And it's better to be | strict up front and lenient later if the public demands it. Ok. So is removal of this a YACC? ;) Clark |
From: Brian I. <in...@tt...> - 2002-04-12 04:19:56
|
On 11/04/02 22:20 -0400, Clark C . Evans wrote: > On Thu, Apr 11, 2002 at 01:17:10PM -0700, Brian Ingerson wrote: > | On 11/04/02 04:50 -0400, Oren Ben-Kiki wrote: > | > Hmmm. Like I said, if both you and Brian feel this way, I'll go with it... > | > Brian? > | > | I think both arguments are compelling. So let's move on to another YAML > | design goal: easy to implement. > | > | I think the single '---' is easiest to implement. And it's better to be > | strict up front and lenient later if the public demands it. > > Ok. So is removal of this a YACC? All signs say --- is the one true way. Make it so number one. Cheers, Brian |
From: Neil W. <neilw@ActiveState.com> - 2002-04-10 06:59:40
|
Oren Ben-Kiki [10/04/02 02:23 -0400]: > I'm not certain I agree. Today's rules allow me to take: [...] > And using simple concatenation create the following: > > ---FILE | > --- | > file 1, doc 1 > --- | > file 1, doc 2 > ---FILE | > --- | > file 2, doc 1 > --- | > file 2, doc 2 Eek! The way _I_ read it, by today's rules, that's an empty block, then a parse error on line 2, because you don't have the same document separator. That's also the way YAML.pm reads it. I suppose we could be wrong... Besides, don't you think that looks really ugly? We can go further and end up with YAML that no one could possibly edit, which is against our primary goal. ---1sadfb123b5ad-- | ---12b4-48vg8r94-- | ---458fbv-==asdf?? ] What's this? --- and this? --- A parse error, you say? ---458fbv-==asdf?? --: not a document separator? ---12b4-48vg8r94-- and again ---1sadfb123b5ad-- ~ Which, of course, is just the same as this: --- | ---12b4-48vg8r94-- | ---458fbv-==asdf?? ] What's this? --- and this? --- A parse error, you say? ---458fbv-==asdf?? --: not a document separator? ---12b4-48vg8r94-- and again --- ~ But did you _know_ that? Did indentation help you? I don't think so. > That is, we can convert any YAML file to a block just by prefixing it with a > header line. I think this is pretty useful. The method of converting things to blocks should be adding a block indicator and indenting by one space. Otherwise lazy programmers like you and I will overpower the poor humans who have to read our trail of incomprehensible YAML. And indenting by one space isn't a huge chore, is it? ycat file1 file2 `ycat' is a very simple program which emits this YAML stream: --- | contents of file1 (indented by 1) --- | contents of file2 (indented by 1) As a final motivator, think of the cool slogan: "Why cat, when you can ycat?" Later, Neil |
From: Clark C . E. <cc...@cl...> - 2002-04-10 15:40:36
|
| That is, we can convert any YAML file to a block just by prefixing it with a | header line. I think this is pretty useful. I can't think of one use case where I'd need that ability and where indenting the two files would not be adequate. As for stream concatination, 99% of the use cases here will be merging log files / transaction journals. And in this case conversion to block is not part of the operation. Now, I do see the use case to include an entire YAML block or text files having -- as a map or seq value. However, the prefix hack doesn't help you here as it only applies at the document level. I claim that this isn't a useful feature beacuse it seems to be only useful in the cross product of two uncommon requirements: (a) converting a free-standing file into a *document* and not a leaf value, and (b) concatinating a stream of arbitrary files to get a sequence of YAML documents, each document with only one block. The whole reason for the --Unique block MIME hack was so that we could have top level scalars including "--" in column one. Before our flexible indenting we needed this hack... now with flexible indenting we don't. The cost vs benifit just isn't there, it is a high cost feature and the return on our investment is very little. To this effect, I had actually removed this feature from my "mental copy" of the YAML spec several months ago. Best, Clark |