From: Oren Ben-K. <or...@ri...> - 2002-01-03 10:25:38
|
Brian Ingerson [mailto:in...@tt...] wrote: > I've finished the YACs. There are currently 18 of them. 7 are > new (from > the list I sent the other day). I'll be out of town until > Sunday. I look > forward to your commentary. First of all, *NICE* work, Brian! Comments: YAC#5: # The examples are wrong, should use # yaml://any/tld.domain.type names. YAC#11: # s/implicitlt/implicitly/ YAC#12: votes: { oren : + } - !yac/comment when: 2002-01-03 who: oren what: | This should probably add the notion of trailing comments at the end of a YAML *stream*, to allow for cases like: map: key: value # key: value YAC#13: votes: { oren : + } # But: - !yac/comment when: 2002-01-03 who: oren what: \ The default indentation of next-line scalars should be auto-detected instead of being one space. You wrote in YAC#14: > ... Often people will start a paragraph > with spaces, which is why using the first > line for default indentation is bad. If one wants to indent the first line, use \#1. I think the majority of the user cases (in config files etc.) goes the other way - paragraphs where the first line is *not* indented, which use other than 1-space indentation. I'll be happy to put this to the test (looking in a reasonable number of config files and the way paragraphs are formatted inside multi-line '#' comment blocks). YAC#14: # Vote witheld at this time... # # That's a major one... I have to come to grips # with ^\+#4. As a one-time Perl programmer, # I can see the sense in it. But I think you'll # have a harder time with the Python and Java # heads. This is exactly the sort of "line noise" # which you have to either love or hate... # # Clark? # - !yac/comment when: 2002-01-03 who: oren what: \ The reasonable default for block is to preserve the newline and for folded to strip it. Your examples imply that this is indeed the case and that therefore there's a need for both '+' to be used for '^' values and '-' to be used for '|' values... if so this should be made explicit. YAC#15: votes: { oren : + } # But: - !yac/comment when: 2002-01-03 who: oren what: \ I like the reasoning and the fact it simplifies the productions (=> implementation as well). I have a problem with the mechanism for distinguishing a directive from a simple value. It is "more YAML" (and simpler) to assign an indicator for a directive, such as '#': --- #YAML:1.0 text '#' is perfectly suitable for the task because it denotes "syntax only" issues, and directives are exactly that. It is already an indicator so that we don't lose any expressive power, and there's no ambiguity with throwaway comments. YAC#16: # This seems just a formalization of the current # intention.... Making it explicit doesn't hurt. # It doesn't help the productions any... votes: { oren : + } YAC#17: votes: { oren : - } - !yac/comment when: 2002-01-03 who: oren what: \ Using language specific names such as yaml://perl/hash instead of the language independent names such as yaml://any/org.yaml.map should be strongly discouraged as it reduces interoperability. I wouldn't vote for any YAC which recommended this practice for any use case. Given the above, I have full confidence that your problem of handling blessed globs can be solved within the yaml://perl/. For example, if you are missing an indicator for 'glob', why don't you just invent one ('^' would work fine: !perl/^Glob::Object). Or you could use !perl/map:Hash::Object and !perl/glob:Glob::Object, or even !perl/hash:Hash::Object... YAC#18: votes: { oren : +++ } Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-01-03 16:48:43
|
Clark C . Evans [mailto:cc...@cl...] wrote: > | YAC#18: > | votes: { oren : +++ } > > YAC#18: > votes: (oren:+++,cce:+++) > - !yac/comment > when: 2002-01-03 > who: cce > what: | > We should do our best to put (tm) or HTML's > <sup><small>(tm)</small></sup> after YAML to > indicate that we are claiming a trademark on YAML (tm). > I will be forming a small charitable non-profit > for YAML in a few months that will own the trademark > and the YAML.ORG domain name. Oren, Brian, and Clark > will be the initial board of directors. Sounds great... The copyright on the spec should be shifted to that as well. BTW, these things require some overhead, unreasonable amount of signed papers, and paying up some registration fees. You are probably more knowledgeable about how such things are done in the USA. Let me know... Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-01-07 08:18:49
|
Brian Ingerson [mailto:in...@tt...] wrote: > > YAC#5: > > # The examples are wrong, should use > > # yaml://any/tld.domain.type names. > > This is from YAC#3.2 under http://www.yaml.org/YAC-list.html#done. > > Could someone please send me a fix for this. It's not really > my domain. Actually, what we settled on is a different YAC. Here's its formulation as YAC#19. BTW, note that using the scheme name 'type:' makes perfect sense now... but let's stick with 'yaml:' anyway :-) --- YAML:1.0 location: http://www.yaml.org/yacs/019 abstract: Uniform URI Mechanism for types owner: cce status: !yac/status state: accepted date: 2002-01-07 proposal: \ Use a uniform URI mechanism for types, not namespaces. rationale: \ Use a single mechanism for all type names. Create a top-level URI scheme yaml: as in YAC#005: make it a generic hierarchical URI for any language specific or generic data type. Use this URI scheme whenever there's no specific scheme specified. The authority is the language name or 'any' for generic types. The hiererchy is defined by the language. Unlike YAC#5, each URI stands for a single type rather than for a namespace. The | character is used as a merely syntactical device to avoid repeating a shared prefix between all types used in a given YAML tree ("data island"). There is no restriction that the prefix up to the | would designate a semantically meaningful "namespace". examples: - | The interpretation of transfer methods would be as follows: Transfer Method Type !type yaml:any/org.yaml.type !/tld.domain.based yaml:any/tld.domain.based !lang/package-and-type yaml:lang/package-and-type !scheme:whatever scheme:whatever dialog: [] votes: [] references: - http://www.yaml.org/yacs/003 - http://www.yaml.org/yacs/004 replaces: http://www.yaml.org/yacs/005 replaced by: Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-01-07 08:33:29
|
Brian Ingerson [mailto:in...@tt...] wrote: > > | leaves the following edge cases though. (Pretend '_' is a space): > > | > > | --- > > | foo: \ > > | _______ > > | Paragraph begins here > > | bar: \ > > | ____ > > | ________ > > | ... > > | > > | What's the indentation level? 4 or 7. > > > > Indentation in both examples is 1 since the > > first line lacks a non-whitespace character. Hmmm. > Oren, > > I just chatted with cce. > > I'll go with using the first non-space one the first line as > long as the > indentation defaults to '1' if the line has no non-space. > Does this work for you? The only thing I dislike about it is it causes me to look ahead all the way to the end of the line before I know what the second space is (content or indentation). Currently our syntax seems devoid of such beasts... And I'm enjoying it very much in my implementation :-) This isn't insurmountable, but it is a wart. Hmmm... What is the down side of saying the indentation is at minimum 1 (if the line is all white spaces and too short), and is the whole line (if it is all white spaces and 'too long')? That is, 7 spaces for 'foo', and 4 spaces for 'bar'? It isn't readability because either your way or mine there's something invisible going on (in my case, what is the indentation level; in your case, the fact there are - or aren't - leading spaces in the value). I say that whoever writes such stuff (having trivial more readable alternatives) deserves "magic" hapenning. Let's keep things as simple as possible: all leading white space in the first line is taken to be indentation (with minimal indentation being taken to be 1). Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2002-01-07 08:56:05
|
| > I'll go with using the first non-space one the first line as | > long as the indentation defaults to '1' if the line has no non-space. | > Does this work for you? | | The only thing I dislike about it is it causes me to look ahead all the way | to the end of the line before I know what the second space is (content or | indentation). Currently our syntax seems devoid of such beasts... And I'm | enjoying it very much in my implementation :-) This isn't insurmountable, | but it is a wart. Hmmm... This is a tiny bit of look-ahead. I'm willing to suffer it since the look-ahead is limited to spaces that I can count with an integer... not so bad of a wart given that it provides for pretty nice flexible indenting. | What is the down side of saying the indentation is at minimum 1 | (if the line is all white spaces and too short), and is the whole | line (if it is all white spaces and 'too long')? That is, 7 spaces | for 'foo', and 4 spaces for 'bar'? This method would cause an indentation error in the second case since a non-space occurs before the indentation level. | I say that whoever writes such stuff (having trivial more readable | alternatives) deserves "magic" hapenning. Let's keep things as simple as | possible: all leading white space in the first line is taken to be | indentation (with minimal indentation being taken to be 1). That's a bit more magical than I'd like... I'd suffer the space-only look-ahead before getting too tricky. Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Brian I. <in...@tt...> - 2002-01-08 04:42:57
|
On 07/01/02 10:34 +0200, Oren Ben-Kiki wrote: > Brian Ingerson [mailto:in...@tt...] wrote: > > > | leaves the following edge cases though. (Pretend '_' is a space): > > > | > > > | --- > > > | foo: \ > > > | _______ > > > | Paragraph begins here > > > | bar: \ > > > | ____ > > > | ________ > > > | ... > > > | > > > | What's the indentation level? 4 or 7. > > > > > > Indentation in both examples is 1 since the > > > first line lacks a non-whitespace character. > > Hmmm. > > > Oren, > > > > I just chatted with cce. > > > > I'll go with using the first non-space one the first line as > > long as the > > indentation defaults to '1' if the line has no non-space. > > Does this work for you? > > The only thing I dislike about it is it causes me to look ahead all the way > to the end of the line before I know what the second space is (content or > indentation). Currently our syntax seems devoid of such beasts... And I'm > enjoying it very much in my implementation :-) This isn't insurmountable, > but it is a wart. Hmmm... > > What is the down side of saying the indentation is at minimum 1 (if the line > is all white spaces and too short), and is the whole line (if it is all > white spaces and 'too long')? That is, 7 spaces for 'foo', and 4 spaces for > 'bar'? How about this... We are proposing that the maximum indentation be 9 spaces (single digit). So, if no explicit indentation is given, we scan the first 9 characters of the first line. If no non-space is found, the indentation is '1'. Cheers, Brian |
From: Oren Ben-K. <or...@ri...> - 2002-01-07 09:32:29
|
I just chatted with Clark about it. We see four options: 1. No auto detection (always use 1). We both feel this is too restrictive. 2. Look ahead to the end of the line (unbound lookahead). If there's no non-space, use 1 space indentation. Otherwise, auto-detect. Note that lookahead can't be just counting spaces due to the existance of tab characters (Brian is right, white space is the work of the devil :-). 3. Look ahead, but if no non-space is found within 9 spaces, take the indentation to be 1. This works nicely with using a single digit for specifying indentation amount. Indentation will *always* be in the range 1-9. This means that: this: ^ __________Has 9 leading spaces and this: ^ ________Has none Which we think is too confusing. 4. Do not look ahead. If the first line is all spaces, they are all taken to be indentation. If there isn't enough spaces (like a completely empty line), the indentation is taken to be the minimum - 1. case 1: ^ ____Starts with \n and 3 spaces. case 2: ^ ________ ________Is indented 10 spaces. case 3: ^ ______ ________Starts with a \n and 2 spaces. ____case 4: ^ __________ ______Is an error ____just like case 5: ^ ________This ______is an error. We feel this is the simplest and best solution. Personally I think that cases 1-4 are pathological enough that it doesn't matter much what we do - as the spaces are invisible it won't be very readable anyway. Better to keep the definition and implementation simple, then. Brian? Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2002-01-08 05:00:52
|
On 07/01/02 11:33 +0200, Oren Ben-Kiki wrote: > I just chatted with Clark about it. We see four options: > > 1. No auto detection (always use 1). We both feel this is too restrictive. OK > 2. Look ahead to the end of the line (unbound lookahead). If there's no > non-space, use 1 space indentation. Otherwise, auto-detect. Note that > lookahead can't be just counting spaces due to the existance of tab > characters (Brian is right, white space is the work of the devil :-). I have another related quandry. Assume that we allow tabs in indentation (which we will need to). What happens when tabs cross the indentation border? foo: ^3 ___First line -(tab)->Second line ___---->Third Line ... Is the second line: - An error - Begins with 5 spaces - Begins with a tab Not a rare case, most likely. > > 3. Look ahead, but if no non-space is found within 9 spaces, take the > indentation to be 1. This works nicely with using a single digit for > specifying indentation amount. Indentation will *always* be in the range > 1-9. This means that: > > this: ^ > __________Has 9 leading spaces > and this: ^ > ________Has none > > Which we think is too confusing. I should have read ahead :) OK. This is a little icky. > > 4. Do not look ahead. If the first line is all spaces, they are all taken to > be indentation. If there isn't enough spaces (like a completely empty line), > the indentation is taken to be the minimum - 1. OK. But to a maximum of 9 chars. > > case 1: ^ > > ____Starts with \n and 3 spaces. > > case 2: ^ > ________ > ________Is indented 10 spaces. Nope. 9 spaces. I think that's easy to explain. > case 3: ^ > ______ > ________Starts with a \n and 2 spaces. > > ____case 4: ^ > __________ > ______Is an error > > ____just like case 5: ^ > ________This > ______is an error. > > We feel this is the simplest and best solution. Personally I think that > cases 1-4 are pathological enough that it doesn't matter much what we do - > as the spaces are invisible it won't be very readable anyway. Better to keep > the definition and implementation simple, then. > > Brian? OK, if max is 9. Cheers, Brian |
From: Oren Ben-K. <or...@ri...> - 2002-01-08 08:02:57
|
Brian Ingerson [mailto:in...@tt...] wrote: > > 1. No auto detection (always use 1). We both feel this is > > too restrictive. > > OK Fine. Scratch that. > > 2. Look ahead to the end of the line (unbound lookahead). > > If there's no > > non-space, use 1 space indentation. Otherwise, auto-detect. > > Note that > > lookahead can't be just counting spaces due to the existance of tab > > characters (Brian is right, white space is the work of the > > devil :-). > > I have another related quandry. Assume that we allow tabs in > indentation > (which we will need to). What happens when tabs cross the > indentation border? *Certainly* work of the devil. > foo: ^3 > ___First line > -(tab)->Second line > ___---->Third Line > ... > > Is the second line: > - An error An error. I *really* want this to be an error. > - Begins with 5 spaces > - Begins with a tab > > Not a rare case, most likely. I should hope not! Leading white space is rare by itself... At any rate, scratch #2. Unbounded lookahead is bad. > > 3. Look ahead, but if no non-space is found within 9 > > spaces, take the > > indentation to be 1. This works nicely with using a single digit for > > specifying indentation amount. Indentation will *always* be > > in the range > > 1-9. This means that: > > > > this: ^ > > __________Has 9 leading spaces > > and this: ^ > > ________Has none > > > > Which we think is too confusing. > > I should have read ahead :) > > OK. This is a little icky. Right. > > 4. Do not look ahead. If the first line is all spaces, they > > are all taken to > > be indentation. If there isn't enough spaces (like a > > completely empty line), > > the indentation is taken to be the minimum - 1. > > OK. But to a maximum of 9 chars. OK, but... > > case 1: ^ > > > > ____Starts with \n and 3 spaces. > > > > case 2: ^ > > ________ > > ________Is indented 10 spaces. > > Nope. 9 spaces. I think that's easy to explain. If it has 9 spaces and a single leading space, that's option #3 - isn't it? > > case 3: ^ > > ______ > > ________Starts with a \n and 2 spaces. > > > > ____case 4: ^ > > __________ > > ______Is an error > > > > ____just like case 5: ^ > > ________This > > ______is an error. > > > > We feel this is the simplest and best solution... > > > > Brian? > > OK, if max is 9. It seems you imply some mixture of #3 and #4. Could you elaborate? Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2002-01-08 21:51:28
|
On 08/01/02 10:03 +0200, Oren Ben-Kiki wrote: > > I have another related quandry. Assume that we allow tabs in > > indentation > > (which we will need to). What happens when tabs cross the > > indentation border? > > *Certainly* work of the devil. > > > foo: ^3 > > ___First line > > -(tab)->Second line > > ___---->Third Line > > ... > > > > Is the second line: > > - An error > > An error. I *really* want this to be an error. Whoa! Bad choice IMO. Ordinary users will not be aware of tabs that their editor inserts. Since we seem to agree that tabs must mean "move to next column of 8", then let's just prenormalize any tab that comes before the first non-space of a given line. Turn leading tabs into spaces first, then the user will get what she expected, regardless of whether or not she is aware of the tabs. > > > 3. Look ahead, but if no non-space is found within 9 > > > spaces, take the > > > indentation to be 1. This works nicely with using a single digit for > > > specifying indentation amount. Indentation will *always* be > > > in the range > > > 1-9. This means that: > > > > > > this: ^ > > > __________Has 9 leading spaces > > > and this: ^ > > > ________Has none > > > > > > Which we think is too confusing. > > > > I should have read ahead :) > > > > OK. This is a little icky. > > Right. > > > > 4. Do not look ahead. If the first line is all spaces, they > > > are all taken to > > > be indentation. If there isn't enough spaces (like a > > > completely empty line), > > > the indentation is taken to be the minimum - 1. > > > > OK. But to a maximum of 9 chars. > > OK, but... > > > > case 1: ^ > > > > > > ____Starts with \n and 3 spaces. > > > > > > case 2: ^ > > > ________ > > > ________Is indented 10 spaces. > > > > Nope. 9 spaces. I think that's easy to explain. > > If it has 9 spaces and a single leading space, that's option #3 - isn't it? Not at all. #3 says that if you go too far, you reset to 1. This says if you go too far you reset to a max of 9. Much more intuitive (relatively speaking :) Now let's go with a max of 8 (which is still single digit) instead of 9. I think saying that "the max indentation is 8" will seem more sane to the general public. If we go with 9, some wanker will start complaining that it should be 10 or 12 or unlimited, etc. I just don't have the patience to deal with that kind of banter. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-01-03 16:33:21
|
Give me till Sunday to respond to all. Sorry... | YAC#18: | votes: { oren : +++ } YAC#18: votes: (oren:+++,cce:+++) - !yac/comment when: 2002-01-03 who: cce what: | We should do our best to put (tm) or HTML's <sup><small>(tm)</small></sup> after YAML to indicate that we are claiming a trademark on YAML (tm). I will be forming a small cheritable non-profit for YAML in a few months that will own the trademark and the YAML.ORG domain name. Oren, Brian, and Clark will be the initial board of directors. 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-03 16:45:15
|
(bad syntax errors, sorry) Give me till Sunday to respond to all. Sorry... | YAC#18: | votes: { oren : +++ } YAC#18: votes: {oren: +++, cce: +} comments: - when: 2002-01-03 who: cce what: \ We should do our best to put (tm) or HTML's <sup><small>(tm)</small></sup> after YAML to indicate that we are claiming a trademark on YAML (tm). I will be forming a small cheritable non-profit for YAML in a few months that will own the trademark and the YAML.ORG domain name. Oren, Brian, and Clark will be the initial board of directors. -- 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-05 19:33:16
|
| First of all, *NICE* work, Brian! Yes. I agree. Thanks _so_ much. | YAC#12: | votes: { oren : + } | - !yac/comment | when: 2002-01-03 | who: oren | what: | | This should probably add the notion of trailing | comments at the end of a YAML *stream*, to allow | for cases like: | | map: | key: value | # key: value YAC#12: votes: { oren: +} - !yac/comment when : 2002-01-05 who : cce what : \ I like the idea. However, I'm unsure about what it will do to the productions and information model. So, I'd like this fleshed out in a bit more detail before a vote. | YAC#13: | votes: { oren : + } | # But: | - !yac/comment | when: 2002-01-03 | who: oren | what: \ | The default indentation of next-line scalars | should be auto-detected instead of being one | space. YAC#13: votes: { oren: +, cce: +} - !yac/comment when : 2002-01-05 who : cce what : \ I approve with Oren's change above, in particular the quote "This indentation is always assumed to be a single space unless an explicit indicator is used." is what must be changed. | | You wrote in YAC#14: | > ... Often people will start a paragraph | > with spaces, which is why using the first | > line for default indentation is bad. | | If one wants to indent the first line, use \#1. I think the majority of the | user cases (in config files etc.) goes the other way - paragraphs where the | first line is *not* indented, which use other than 1-space indentation. I'll | be happy to put this to the test (looking in a reasonable number of config | files and the way paragraphs are formatted inside multi-line '#' comment | blocks). --- note: I agree with Oren here. example: | int func(void) { return 2; } | YAC#14: | # Vote witheld at this time... | # | # That's a major one... I have to come to grips | # with ^\+#4. As a one-time Perl programmer, | # I can see the sense in it. But I think you'll | # have a harder time with the Python and Java | # heads. This is exactly the sort of "line noise" | # which you have to either love or hate... | # | - !yac/comment | when: 2002-01-03 | who: oren | what: \ | The reasonable default for block is to preserve | the newline and for folded to strip it. Your | examples imply that this is indeed the case and | that therefore there's a need for both '+' to be | used for '^' values and '-' to be used for '|' | values... if so this should be made explicit. YAC#14: - !yac/comment when : 2002-01-05 who : cce what : background: \ summary: \ I like the general idea. When I was writing out the "C" API header a few weeks ago, I did two things: one: \ I merged "style" with "kind". In the tree model, there were three kinds { BRANCH, LEAF, ALIAS } and in the syntax model, there were { MAP, SEQ, BLOCK, FOLDED, PLAIN, QUOTED, INLINE_MAP, INLINE_SEQ, etc. } two: | Each one of these syntax kinds was a bit-field consisting of (fBRANCH vs fLEAF), (fESCAPED vs fUNESCAPED), (fINLINE vs fNEXTLINE), (fFOLDED vs fBLOCK), and (fXTRALINE vs fCHOMP). For example... QUOTED = fLEAF | fBLOCK | fESCAPED | fINLINE | fCHOMP BLOCK = fLEAF | fBLOCK | fUNESCAPED | fNEXTLINE | fXTRALINE FOLDED = fLEAF | fFOLDED | fUNESCAPED | fNEXTLINE | fCHOMP general: \ So. In general, I think we think alike. You seem to be normalizing the syntax based on the properties. I think we should do this at the API level, however I'm not so sure that we should do this at the syntax level. In particular, to CHOMP or not to CHOMP really only applies to block scalars, I don't think that this property applies to other types of scalars. If we did go this route, I'd question if we need a sigal to distinguish between in-line and next-line? This would get rid of the single vs double quote stuff... conclusion: \ Overall, I think that this proposal reduces readability by making the syntax more regular (and more directly reflect the API). I'm not so sure that this is a step forward, as normalization can occur just wonderfully in the API as it stands... certainly some API combinations won't be serializable, but this can just be an error condition in the serializer... | YAC#15: | votes: { oren : + } | # But: | - !yac/comment | when: 2002-01-03 | who: oren | what: \ | I like the reasoning and the fact it simplifies | the productions (=> implementation as well). I | have a problem with the mechanism for | distinguishing a directive from a simple value. | It is "more YAML" (and simpler) to assign an | indicator for a directive, such as '#': | | --- #YAML:1.0 text | | '#' is perfectly suitable for the task because | it denotes "syntax only" issues, and directives | are exactly that. It is already an indicator so | that we don't lose any expressive power, and | there's no ambiguity with throwaway comments. YAC#15: votes: { oren: +, cce: + } - !yac/comment when : 2002-01-05 who : cce what : \ I'll go with it as ammended by Oren. I'm not set on the # indicator, this can be changed if need be. However, the indicatorish approach is more consistent with our current set of productions. | YAC#16: | # This seems just a formalization of the current | # intention.... Making it explicit doesn't hurt. | # It doesn't help the productions any... | votes: { oren : + } YAC#16: votes: { oren: +, cce: + } | YAC#17: | votes: { oren : - } | - !yac/comment | when: 2002-01-03 | who: oren | what: \ | Using language specific names such as | yaml://perl/hash instead of the language | independent names such as yaml://any/org.yaml.map | should be strongly discouraged as it reduces | interoperability. I wouldn't vote for any YAC | which recommended this practice for any use case. | | Given the above, I have full confidence that your | problem of handling blessed globs can be solved | within the yaml://perl/. For example, if you are | missing an indicator for 'glob', why don't you | just invent one ('^' would work fine: | !perl/^Glob::Object). Or you could use | !perl/map:Hash::Object and !perl/glob:Glob::Object, | or even !perl/hash:Hash::Object... YAC#17: votes: { cce: + } - !yac/comment when : 2002-01-05 who : cce what : \ This non-sigal based approach seems wonderful. To handle Oren's concern, the binding should try to use !map instead of !perl/hash when the hash is not blessed. For the blessed case, !perl/hash:Foo::Bar works well. Nice Brian. SUMMARY: \ I'd like #12 to be fleshed out more, and if my thoughts on #14 don't cause the proposal to be withdrawn, then a bit more discussion would be cool. I'm not opposed to #14 as much as I don't want the syntax to suffer... Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Brian I. <in...@tt...> - 2002-01-07 01:48:04
|
On 03/01/02 12:26 +0200, Oren Ben-Kiki wrote: > Brian Ingerson [mailto:in...@tt...] wrote: > > I've finished the YACs. There are currently 18 of them. 7 are > > new (from > > the list I sent the other day). I'll be out of town until > > Sunday. I look > > forward to your commentary. > > First of all, *NICE* work, Brian! Aww shucks fellas. > > Comments: > > YAC#5: > # The examples are wrong, should use > # yaml://any/tld.domain.type names. This is from YAC#3.2 under http://www.yaml.org/YAC-list.html#done. Could someone please send me a fix for this. It's not really my domain. > > YAC#11: > # s/implicitlt/implicitly/ done. I'll reply to the more serious stuff separately. Cheers, Brian |
From: Brian I. <in...@tt...> - 2002-01-07 03:29:03
|
On 03/01/02 12:26 +0200, Oren Ben-Kiki wrote: > Brian Ingerson [mailto:in...@tt...] wrote: > YAC#12: > votes: { oren : + } > - !yac/comment > when: 2002-01-03 > who: oren > what: | > This should probably add the notion of trailing > comments at the end of a YAML *stream*, to allow > for cases like: > > map: > key: value > # key: value This becomes a non-issue with this YAC. Basically any line at any indentation level gets thrown away unless it can be gobbled by a multiline. > > YAC#13: > votes: { oren : + } > # But: > - !yac/comment > when: 2002-01-03 > who: oren > what: \ > The default indentation of next-line scalars > should be auto-detected instead of being one > space. > > You wrote in YAC#14: > > ... Often people will start a paragraph > > with spaces, which is why using the first > > line for default indentation is bad. > > If one wants to indent the first line, use \#1. I think the majority of the > user cases (in config files etc.) goes the other way - paragraphs where the > first line is *not* indented, which use other than 1-space indentation. I'll > be happy to put this to the test (looking in a reasonable number of config > files and the way paragraphs are formatted inside multi-line '#' comment > blocks). OK. I'm willing to go with autoindenting by first starting character. It leaves the following edge cases though. (Pretend '_' is a space): --- foo: \ _______ Paragraph begins here bar: \ ____ ________ ... What's the indentation level? 4 or 7. If 4, does the first line contain three spaces? What does the second example mean? This is one reason that I favor single space as the default. It's precise. I'm not sure why people would want more than single space. If they do, they can be explicit. > YAC#14: > # Vote witheld at this time... > # > # That's a major one... I have to come to grips > # with ^\+#4. As a one-time Perl programmer, > # I can see the sense in it. But I think you'll > # have a harder time with the Python and Java > # heads. This is exactly the sort of "line noise" > # which you have to either love or hate... > # > # Clark? > # > - !yac/comment > when: 2002-01-03 > who: oren > what: \ > The reasonable default for block is to preserve > the newline and for folded to strip it. Your > examples imply that this is indeed the case and > that therefore there's a need for both '+' to be > used for '^' values and '-' to be used for '|' > values... if so this should be made explicit. '+' was just a thought. I just wanted to show the extensibility. Let's drop '+'. > > YAC#15: > votes: { oren : + } > # But: > - !yac/comment > when: 2002-01-03 > who: oren > what: \ > I like the reasoning and the fact it simplifies > the productions (=> implementation as well). I > have a problem with the mechanism for > distinguishing a directive from a simple value. > It is "more YAML" (and simpler) to assign an > indicator for a directive, such as '#': > > --- #YAML:1.0 text > > '#' is perfectly suitable for the task because > it denotes "syntax only" issues, and directives > are exactly that. It is already an indicator so > that we don't lose any expressive power, and > there's no ambiguity with throwaway comments. I like this. It means we could conceivably use directives at any level if we needed to. Cool. The only downside is changing a bunch of examples :) Hmm. Since unknown directives are simply ignored, I think we should start ignoring them at any level. See. Even cleaner productions! > > YAC#16: > # This seems just a formalization of the current > # intention.... Making it explicit doesn't hurt. > # It doesn't help the productions any... > votes: { oren : + } Well previously, a headerless stream == a single document stream. Now a headerless stream is simply a headerless stream. # Two identical documents here. # First: foo: bar # Second: --- foo: bar ... If this is cool by you guys, then hurray! > YAC#17: > votes: { oren : - } btw, please use: votes: - !yac/vote who: oren what: nay when: 2002-01-03 why: optional summary > - !yac/comment > when: 2002-01-03 > who: oren > what: \ > Using language specific names such as > yaml://perl/hash instead of the language > independent names such as yaml://any/org.yaml.map > should be strongly discouraged as it reduces > interoperability. I wouldn't vote for any YAC > which recommended this practice for any use case. > > Given the above, I have full confidence that your > problem of handling blessed globs can be solved > within the yaml://perl/. For example, if you are > missing an indicator for 'glob', why don't you > just invent one ('^' would work fine: > !perl/^Glob::Object). Or you could use > !perl/map:Hash::Object and !perl/glob:Glob::Object, > or even !perl/hash:Hash::Object... Let me restate. My specific goal is to get away from the special sigils, and to replace it with something scalable. Specific use cases: --- - old: !perl/Hash new: !perl/hash:Blessed::Hash - old: !perl/@Blessed::Array new: !perl/array:Blessed::Array - old: !perl/$Blessed::Scalar new: !perl/scalar:Blessed::Scalar - old: !perl/:glob new: !perl/glob - old: !perl/:code new: !perl/code # I realized that I needed these too: - new: !perl/glob:Blessed::Glob - new: !perl/code:Blessed::Code - new: !perl/regex:Blessed::Regex # This seems nice and clean compared to adding sigil types # # Now, I *could* add these shortcuts - new: !perl/:Blessed::Hash - new: !perl/@:Blessed::Array - new: !perl/$:Blessed::Scalar - new: !perl/*:Blessed::Glob - new: !perl/&:Blessed::Code - new: !perl/~:Blessed::Regex # But right now, I don't see a reason to bother. ... This seemed so clean, that I have already implemented it. Now, after inventing this, I realized that someone (not my default emission) might end up saying !perl/hash, which is semantically the same as !map. I could issue a warning here, or make it an error, or accept it. It's merely a side effect; *not* my main intent. > > YAC#18: > votes: { oren : +++ } Yay! Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-01-07 06:35:43
|
| OK. I'm willing to go with autoindenting by first starting character. It | leaves the following edge cases though. (Pretend '_' is a space): | | --- | foo: \ | _______ | Paragraph begins here | bar: \ | ____ | ________ | ... | | What's the indentation level? 4 or 7. Indentation in both examples is 1 since the first line lacks a non-whitespace character. | Now, after inventing this, I realized that someone (not my default | emission) might end up saying !perl/hash, which is semantically the same | as !map. I could issue a warning here, or make it an error, or accept | it. It's merely a side effect; *not* my main intent. Right. I think the choice is up to you, I'd issue a "interoperability warning". Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Brian I. <in...@tt...> - 2002-01-07 07:38:29
|
On 07/01/02 01:51 -0500, Clark C . Evans wrote: > | OK. I'm willing to go with autoindenting by first starting character. It > | leaves the following edge cases though. (Pretend '_' is a space): > | > | --- > | foo: \ > | _______ > | Paragraph begins here > | bar: \ > | ____ > | ________ > | ... > | > | What's the indentation level? 4 or 7. > > Indentation in both examples is 1 since the > first line lacks a non-whitespace character. Oren, I just chatted with cce. I'll go with using the first non-space one the first line as long as the indentation defaults to '1' if the line has no non-space. Does this work for you? Cheers, Brian |