From: Oren Ben-K. <or...@ri...> - 2001-11-08 09:15:07
|
I think I missed the point of the latest ideas. I've no problem with renaming "list" to "sequence", though I think that: empty: !sequence Is a bit too much. Would using 'seq' be acceptable? As a part-time Perl programmer I've never noticed the difference between list and array, and I *did* read the Camel book cover-to-cover. For example, how does one declare a list variable? Python tuples vs. lists can be neatly covered by an explicit type (as would Perl arrays vs. lists if there is such a thing). If you feel that we should define two additional core/common types, 'list' and 'tuple', in addition to 'seq', so be it - as long as you can come up with a good language-independent definition of seq, list and tuple which would make sense to, say, a Java or a C++ programmer :-) About attaching descriptors to the top-level. That's covered in today's spec: !typed - top-level list !typed top-level : map !typed \ top-level scalar !typed top-level map key : with value No need for magical comments. Also, adding descriptors to the top-level prevents concatenation (unless you allow for separators), be it using the above current syntax or using magical type comments (Ugh!). Speaking of which, I *strongly* feel that placing *any* standard YAML semantics in '#...' comments is a serious mistake. Separators: I'm warming up towards the separator syntax. - It allows safe splitting: Note Splitting != Concatenation. Separators make *splitting* safe, in the sense that it is always safe to textually cut a YAML document surrounded by separators and feed it into a YAML system on its own. This is *not* true for a top-level list entry, because it may contain references to nodes in previous list entries. *Concatenating* is safe for both - you can always attach another top-level list entry at the end, same as you can attach another separated document. - It allows for concatenation even if there are top-level descriptors. --- !type1 ... --- !type2 ... --- - It allows us to *NOT* indent top level scalars: --- \ Unindented top-level scalar, hurrah! --- In fact I'd make the separator mandatory if there are top-level descriptors or indicators (there's your place to add a YAML version if we ever need one). I rather like this and I think that so would Brian. The beauty of it that the above is almost exactly covered by the current spec. Repeated map keys - I like Clark's idea of making the first key win (for overriding configuration file entries). I think this should be reported as a warning by the parser, however. Indentation, I gather Brian's idea is "use tab for two 4-space levels". I see a big problem with it. What happens when one writes SP SP SP SP TAB: is that 2 or 3 levels of indentation? An editor/printer will display is as two, but it would actually be three (A possibly unrelated fact is that really old testament books were written without white space, which lends some credit to Brian's opinion of where white space comes from :-) At any rate, I think the only valid options we have are tabs only or 4 spaces only. Anything else is a mess. I don't care which one we choose, as along as we inhume this vampire (chop off its head, put some dirt in its moth, a stake through its heart, and bury it under a crossroad). In short, I'm for keeping things as they are in the current draft. It is better then we give it credit for. With minor changes: - indentation (maybe), - changing 'list' to 'sequence' (and *maybe* adding list/tuple), - going through the production to verify the above top-level descriptors/indicators idea works, I think it would make for a good release candidate. Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-11-08 13:51:30
|
On Thu, Nov 08, 2001 at 11:15:41AM +0200, Oren Ben-Kiki wrote: | I think I missed the point of the latest ideas. I believe Brian's need for a new top level separator construct is that he has two different "types" of sequences: lists and arrays; or as you call them vector and array. Rather than introducing a brand-new top level syntax for vectors (which would only apply at the top level). I was proposing that he use typing rather than introducing a new syntax. | I've no problem with renaming "list" to "sequence", | though I think that: | | empty: !sequence | | Is a bit too much. Would using 'seq' be acceptable? Fine. | As a part-time Perl programmer I've never noticed the | difference between list and array, and I *did* read the | Camel book cover-to-cover. For example, how does one | declare a list variable? From Brian's examples, the "list" type seems to be introduced during function calls and returns; my father calls these fellas "transfer vector" as this was standard IBM 360 word used to describe the variables put on and retrieved from the stack during a function call. | Python tuples vs. lists can be neatly covered by an | explicit type (as would Perl arrays vs. lists if there | is such a thing). If you feel that we should | define two additional core/common types, 'list' | and 'tuple', in addition to 'seq', so be it - as long | as you can come up with a good language-independent | definition of seq, list and tuple which would make | sense to, say, a Java or a C++ programmer :-) ok. | About attaching descriptors to the top-level. That's | covered in today's spec: | | !typed | - top-level list ok. One question. If I have two of these buggers and then I concatinate them I get... !typed - top level list !typed - top level list Is this valid? This is the reason why I chose the comment syntax. | !typed | top-level : map I'm confused with this one. Is the top-level key typed, or is the map? Another good reason why the comment syntax works. | | !typed \ | top-level scalar This is a good example of why I don't like top-level scalars. One could just as easily add a "-" in front, and then we don't have to have special production rules... this works especially well if the type of the top level list is a "transfer vector". | !typed top-level map key : with value Kinda subtle hunh? !typed "top level map key" : with value? | No need for magical comments. if you don't like the magical comments, that's ok. But how do we do concatination of docs in this case? | Also, adding descriptors to the top-level prevents | concatenation (unless you allow for separators), be | it using the above current syntax or using magical | type comments (Ugh!). Speaking of which, I *strongly* | feel that placing *any* standard YAML semantics in | '#...' comments is a serious mistake. Ok. Then let's burn a "special" indicator to mark version and give discriptos to top level constructs. Let's use, for example the ? ?YAML v1.0 !vector The advantage of this is that we don't need another sequential construct. We add a single "roadsign" (later road signs must be identical or it is an error), remove top level scalars, and we are done. Best, Clark |
From: Clark C . E. <cc...@cl...> - 2001-11-08 14:17:15
|
I'd rather stick to top level sequence (-) xor map (:) syntax and add a "?YAML v1.0 !vector" declaration. / Separators: I'm warming up towards the separator syntax. | | - It allows safe splitting: | | Note Splitting != Concatenation. Separators make *splitting* safe, in the | sense that it is always safe to textually cut a YAML document surrounded by | separators and feed it into a YAML system on its own. This is *not* true for | a top-level list entry, because it may contain references to nodes in | previous list entries. *Concatenating* is safe for both - you can always | attach another top-level list entry at the end, same as you can attach | another separated document. | | - It allows for concatenation even if there are top-level descriptors. | | --- !type1 | ... | --- !type2 | ... | --- | | - It allows us to *NOT* indent top level scalars: | | --- \ | Unindented top-level scalar, hurrah! | --- | | In fact I'd make the separator mandatory if there are top-level descriptors | or indicators (there's your place to add a YAML version if we ever need | one). I rather like this and I think that so would Brian. The beauty of it | that the above is almost exactly covered by the current spec. | | Repeated map keys - I like Clark's idea of making the first key win (for | overriding configuration file entries). I think this should be reported as a | warning by the parser, however. | | Indentation, I gather Brian's idea is "use tab for two 4-space levels". I | see a big problem with it. What happens when one writes SP SP SP SP TAB: is | that 2 or 3 levels of indentation? An editor/printer will display is as two, | but it would actually be three (A possibly unrelated fact is that really old | testament books were written without white space, which lends some credit to | Brian's opinion of where white space comes from :-) | | At any rate, I think the only valid options we have are tabs only or 4 | spaces only. Anything else is a mess. I don't care which one we choose, as | along as we inhume this vampire (chop off its head, put some dirt in its | moth, a stake through its heart, and bury it under a crossroad). | | In short, I'm for keeping things as they are in the current draft. It is | better then we give it credit for. With minor changes: | | - indentation (maybe), | - changing 'list' to 'sequence' (and *maybe* adding list/tuple), | - going through the production to verify the above top-level | descriptors/indicators idea works, | | I think it would make for a good release candidate. |