From: Clark C. E. <cc...@cl...> - 2004-09-13 02:44:29
|
I just finished a beer with Mark, a friend of mine (a PyYAML and soon to be Syck user), and we talked about YAML 1.1. He really liked the %TAG idea, but was very concerned about breaking his documents, which I guess are at several client sites, etc. I reviewed the compatibility issues with him: --- - issue: we are getting ride of the ^ character in tags reason: this mechanism is replaced by the %TAG method solution: Parsers can warn, but continue to provide current cut & paste behavior; in other words, this does not create an ambiguity. - issue: the %YAML:1.0 declaration is not per document reason: headers are now stream level solution: Newer parsers can simply warn for now, as this case is not ambiguous. - issue: "23" and 23 are parsed the same note: this has not yet been approved by Brian reason: plain style flag is no longer reported to appliction solution: - if the document has either of the above two items, it is clearly a 1.0 document, and backward-compatible behavior is possible - if the document contains %YAML 1.1 directive, then it is clearly 1.1 document, and the distinction can be safely ignored - in YAML 1.1, there really isn't a need to use the double-quoted "23", so all other cases should ignore the distinction, but issue a warning; and perhaps install a parser option - issue: ! vs !! types reason: beacuse it is deemed that private types are more important and should get the simple form? solution: If it is clearly 1.0 or 1.1 document, there is no problem. Otherwise, the user will most likely encounter a 'tag not resolved' error if things are confused. Anyway, a few more notes about our conversation: - His driving reason for using YAML over 'shelve' or similar Python serialization was: (a) promise of being able to read the files from Perl, and perhaps eventually Java, (b) and readability a 'distant' second. - He uses the 'strings-are-king' version of PyYaml, with frequent !!private types and an occasional !yaml type (for integers). He expressed frustration with the implicit typing, and thought it should be strictly optional (see below). - He didn't care one way or the other about 23 vs "23", as his particular application doesn't mix numbers and strings (aka he has a context-based schema). - He expressed that he'd rather not see ! and !! swapped. He reiterated that the promise of multi-language data files was the primary reason for adopting YAML. He expressed that he'd like to see more YAML types, like !regex, !url and other "botique" data types. He thought a smarter YAML Dumper would use more !yaml types instead of making them private. - He suggested a %REGEX directive that maps regular expressions onto tags. He said he'd consider implicit typing only if it was explicitly in the file so there was no chance of a "mixup". - He very much would like better parsers, emitters, and asked when we will have a schema language to help with validation. He asked about the "Java Version" about 5x stating that he'd love to share the same configuration/data files between the perl junkies, the python heads, and the Java people. After this conversation, I got to thinking a bit about the last item, swapping "!" and "!!". My friend went so far to say that it was a 'fine decision', and was not convinced by our rationale to change it. As a side note, if we didn't swap their meaning we keep backwards compatibility with PyYaml, and also, we can explicitly type something a string by using ! 23 instead of !! 23. So. Do we really want to swap ! and !! -- anyone care to chime in? Kind Regards, Clark |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-13 03:42:23
|
On Sunday 12 September 2004 10:44 pm, Clark C. Evans wrote: > - > =A0 issue: we are getting ride of the ^ character in tags > =A0 reason: > =A0 =A0 this mechanism is replaced by the %TAG method > =A0 solution: > =A0 =A0 Parsers can warn, but continue to provide current > =A0 =A0 cut & paste behavior; in other words, this does not > =A0 =A0 create an ambiguity. > - On this: Since it doesn't break anything to keep it, that would be one less= =20 incompatibility. It can then be phased out at some point in the future.=20 Considering the current changes, it would be one less thing to worry about = at=20 the moment. =2D-=20 ( o _ // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. =2DMark Twain |
From: Oren Ben-K. <or...@be...> - 2004-09-13 04:02:33
|
On Monday 13 September 2004 06:42, trans. (T. Onoma) wrote: > > - > > =A0 issue: we are getting ride of the ^ character in tags > > On this: Since it doesn't break anything to keep it, that would be > one less incompatibility. It can then be phased out at some point in > the future. Considering the current changes, it would be one less > thing to worry about at the moment. =2D1. Its much better to have one break in compatibility than two separate= =20 ones. Getting rid of ^ isn't worth making YAML 1.2 :-) Have fun, Oren Ben-Kiki |
From: Tim H. <tim...@co...> - 2004-09-13 04:12:00
|
Clark C. Evans wrote: >I just finished a beer with Mark, a friend of mine (a PyYAML and >soon to be Syck user), and we talked about YAML 1.1. He really >liked the %TAG idea, but was very concerned about breaking his >documents, which I guess are at several client sites, etc. > >I reviewed the compatibility issues with him: > > I'm going to pretend it's a survey. Hooray a survey! >--- >- > issue: we are getting ride of the ^ character in tags > reason: > this mechanism is replaced by the %TAG method > solution: > Parsers can warn, but continue to provide current > cut & paste behavior; in other words, this does not > create an ambiguity. > > This one won't be an issue for me at all. >- > issue: the %YAML:1.0 declaration is not per document > reason: > headers are now stream level > solution: > Newer parsers can simply warn for now, as this case > is not ambiguous. > > I don't think this one is either, I never put declarations in. A bad habit that helps me here, but is going to bite me down below.. >- > issue: "23" and 23 are parsed the same > note: this has not yet been approved by Brian > reason: > plain style flag is no longer reported to appliction > solution: > - if the document has either of the above two items, > it is clearly a 1.0 document, and backward-compatible > behavior is possible > - if the document contains %YAML 1.1 directive, then > it is clearly 1.1 document, and the distinction can > be safely ignored > - in YAML 1.1, there really isn't a need to use the > double-quoted "23", so all other cases should ignore > the distinction, but issue a warning; and perhaps > install a parser option > > This is the one that's going to bite me. Friendly YAML loaders should be invokable in a 1.0 mode so that we get the 1.0 behaviour even if it's not obvious from the file. What I'll probably end up doing is using a different suffix for my YAML 1.1 files to distinguish them from the 1.0 files. Then I'll invoke the loader in the appropriate mode based on the file suffix. Not elegant, but it'll work for me. Worst comes to worst I can just use an old version of PyYaml for that. >- > issue: ! vs !! types > reason: > beacuse it is deemed that private types are more > important and should get the simple form? > solution: > If it is clearly 1.0 or 1.1 document, there is no problem. > Otherwise, the user will most likely encounter a 'tag not > resolved' error if things are confused. > > This won't affect me either. Till now I've relied soley on implicit types. That's going to have to change. >Anyway, a few more notes about our conversation: > >- His driving reason for using YAML over 'shelve' or similar Python > serialization was: (a) promise of being able to read the files > from Perl, and perhaps eventually Java, (b) and readability a > 'distant' second. > > I'm more or less the opposite. I'm using it a lot as a human readable version of selve. Also as config files. >- He uses the 'strings-are-king' version of PyYaml, with frequent > !!private types and an occasional !yaml type (for integers). He > expressed frustration with the implicit typing, and thought it > should be strictly optional (see below). > > I agree with this. It's easy to turn strings into concrete data, but hard to go the other way. >- He didn't care one way or the other about 23 vs "23", as his > particular application doesn't mix numbers and strings (aka he > has a context-based schema). > >- He expressed that he'd rather not see ! and !! swapped. He > reiterated that the promise of multi-language data files was the > primary reason for adopting YAML. He expressed that he'd like to > see more YAML types, like !regex, !url and other "botique" data > types. He thought a smarter YAML Dumper would use more !yaml > types instead of making them private. > > That sounds sensible to me. >- He suggested a %REGEX directive that maps regular expressions onto > tags. He said he'd consider implicit typing only if it was > explicitly in the file so there was no chance of a "mixup". > > Interesting. If there was %REGEX based typing could it distinguish between 23 and "23"? Would this be a way to preserve the current implicit typing behaviour, distinguishing quoted from unquoted strings, while still abolishing the wart? I might really like this idea. It allows you to pull in whatever subset of implicit typing that you want. All the implicit typing could be in the these tags and the rest of the loader could get simpler. Any details on how this would work? > >- He very much would like better parsers, emitters, and asked > when we will have a schema language to help with validation. > He asked about the "Java Version" about 5x stating that he'd > love to share the same configuration/data files between > the perl junkies, the python heads, and the Java people. > > Hear! Hear! >After this conversation, I got to thinking a bit about the last >item, swapping "!" and "!!". My friend went so far to say that it >was a 'fine decision', and was not convinced by our rationale to >change it. As a side note, if we didn't swap their meaning we keep >backwards compatibility with PyYaml, and also, we can explicitly >type something a string by using ! 23 instead of !! 23. So. Do we >really want to swap ! and !! -- anyone care to chime in? > > It doesn't affect me in the short run, but the arguments that Mark makes here resonate with me: backwards compatability and emphasizing a rich set of YAML types. I don't feel super strongly about this though. -tim |
From: Clark C. E. <cc...@cl...> - 2004-09-13 04:28:48
|
On Sun, Sep 12, 2004 at 09:11:46PM -0700, Tim Hochberg wrote: | > issue: "23" and 23 are parsed the same | | This is the one that's going to bite me. | | > issue: ! vs !! types | | This won't affect me either. Till now I've relied soley on implicit | types. That's going to have to change. | | >- His driving reason for using YAML over 'shelve' or similar Python | > serialization was: (a) promise of being able to read the files | > from Perl, and perhaps eventually Java, (b) and readability a | > 'distant' second. | > | > | I'm more or less the opposite. I'm using it a lot as a human readable | version of selve. Also as config files. I'm also the opposite, most of my use cases are 'log' files (which are almost never rescanned) and hand-edited content files that are used for business documents, and to generate surveys. I do admit to using the cross-platform thing, data files I have in YAML are being used by someone via perl. I was totally suprised to see this, but it naturally emerged. | >- He expressed that he'd rather not see ! and !! swapped. | | That sounds sensible to me. | | >- He suggested a %REGEX directive that maps regular expressions onto | > tags. He said he'd consider implicit typing only if it was | > explicitly in the file so there was no chance of a "mixup". | | Interesting. If there was %REGEX based typing could it distinguish | between 23 and "23"? Would this be a way to preserve the current | implicit typing behaviour, distinguishing quoted from unquoted strings, | while still abolishing the wart? Yes. I'll follow up in another post. | >- He very much would like better parsers, emitters, and asked | > when we will have a schema language to help with validation. | > He asked about the "Java Version" about 5x stating that he'd | > love to share the same configuration/data files between | > the perl junkies, the python heads, and the Java people. | | Hear! Hear! *takes a hint* Best, Clark |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-13 04:33:38
|
On Monday 13 September 2004 12:11 am, Tim Hochberg wrote: > >- He suggested a %REGEX directive that maps regular expressions onto > > =A0tags. =A0He said he'd consider implicit typing only if it was > > =A0explicitly in the file so there was no chance of a "mixup". > > =A0 > > Interesting. =A0If there was =A0%REGEX based typing could it distinguish > between 23 and "23"? Would this be a way to preserve the current > implicit typing behaviour, distinguishing quoted from unquoted strings, > while still abolishing the wart? > > I might really like this idea. It allows you to pull in whatever subset > of implicit typing that you want. All the implicit typing could be in > the these tags and the rest of the loader could get simpler. > > Any details on how this would work? This goes back to style being part of representation again. It can be done,= =20 but it has it's own set of trade offs. =2D-=20 ( o _ // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. =2DMark Twain |
From: Oren Ben-K. <or...@be...> - 2004-09-13 04:30:28
|
On Monday 13 September 2004 05:44, Clark C. Evans wrote: > I reviewed the compatibility issues with him: > > --- > - > issue: we are getting ride of the ^ character in tags > solution: > Parsers can warn, but continue to provide +1. Didn't bother Mark, either. > issue: the %YAML:1.0 declaration is not per document > solution: > Newer parsers can simply warn for now, +1, similarly. > issue: "23" and 23 are parsed the same > solution: (if clearly 1.0 or 1.1 do the 1.0 or 1.1 thing, otherwise assume it is 1.1 and hope for the best). +1. The main point of #4 was that this isn't used in practice anyway. Mark agrees. > issue: ! vs !! types > solution: (same as above). +0. I fully agree with Mark on this. I only agree with this break in compatibility because Brian firmly put his foot down. IMO switching ! and !! back to their compatible meaning makes a ton more sense. I think that private tags _are_ second class to the "common YAML types". > Anyway, a few more notes about our conversation: > [Mark] > expressed frustration with the implicit typing, and thought it > should be strictly optional (see below). Double frustration. It _is_ optional! Whatever gave him the idea it is mandatory? > - He suggested a %REGEX directive... Admittedly, today this would require each implementation to _manually_ code the set of implicit (and private tags, and global tags that aren't from yaml.org). So using %REGEXP would not remove the need to communicate his intent. Inevitable fact of life: If you want to share files between two implementations, you MUST communicate your intent ("what I mean by things" == schema). Yes, it would be easier given a schema language. I strongly feel it is wrong to embed arbitrary subsets of it in the document itself in the meanwhile. > So. Do we > really want to swap ! and !! -- anyone care to chime in? We only did it because of Brian. We need his OK to keep the compatibility. I think his problem is that perl used "!perl/Stuff" all over the place, so NOT switching breaks compatibility for Perl code. In the transition period his parser can detect '!perl/stuff' and (with a warning) convert it to "!!stuff", but it still would be a pain for him. Of course, now that we have two systems - Perl and Python - each pushing in a different direction, I'd rather rule in favor of the one more compatible with the spec :-) Have fun, Oren Ben-Kiki |
From: why t. l. s. <yam...@wh...> - 2004-09-13 04:35:50
|
Clark C. Evans (cc...@cl...) wrote: > - > issue: "23" and 23 are parsed the same > note: this has not yet been approved by Brian > reason: > plain style flag is no longer reported to appliction Can anyone direct me to a succinct explanation of why this must change? I love having two types of scalars. I've seen the massive threads debating this, but can I get a summary in a sentence or two? My simple argument for keeping it would be that I like having a DWIM scalar and a raw scalar. I love this feature, it has never been a wart to me. _why |
From: Oren Ben-K. <or...@be...> - 2004-09-13 04:48:45
|
On Monday 13 September 2004 07:54, why the lucky stiff wrote: > Can anyone direct me to a succinct explanation of why this must > change? I love having two types of scalars. I've seen the massive > threads debating this, but can I get a summary in a sentence or two? Because nobody ever uses it in practice, and it _is_ a wart :-) > My simple argument for keeping it would be that I like having a DWIM > scalar and a raw scalar. I love this feature, it has never been a > wart to me. Well, in practice every scalar is either a "DWIM" or has a specific expected type based on the path leading to it. No need for the plain flag. In the very rare cases you have a scalar that is neither, use "!". Have fun, Oren Ben-Kiki |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-13 04:54:29
|
On Monday 13 September 2004 12:48 am, Oren Ben-Kiki wrote: > On Monday 13 September 2004 07:54, why the lucky stiff wrote: > > Can anyone direct me to a succinct explanation of why this must > > change? I love having two types of scalars. I've seen the massive > > threads debating this, but can I get a summary in a sentence or two? > > Because nobody ever uses it in practice, and it _is_ a wart :-) Honestly! That is not true. It might not be used a lot, but it gets used a little here and a little there. So _never_ is not the case. If it were, you wouldn't be telling us how to work around it below. > > My simple argument for keeping it would be that I like having a DWIM > > scalar and a raw scalar. I love this feature, it has never been a > > wart to me. > > Well, in practice every scalar is either a "DWIM" or has a specific > expected type based on the path leading to it. No need for the plain > flag. In the very rare cases you have a scalar that is neither, use > "!". T. -- ( o _ // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. -Mark Twain |
From: Clark C. E. <cc...@cl...> - 2004-09-13 06:33:44
|
Regarding, the idea that "23" and 23 being reported as the same, the feedback seems to be quite clear: On Mon, Sep 13, 2004 at 12:40:01AM -0400, trans. (T. Onoma) wrote: | This is the one I find hardest to swallow. On Sun, Sep 12, 2004 at 09:11:46PM -0700, Tim Hochberg wrote: | This is the one that's going to bite me. On Mon, Sep 13, 2004 at 12:54:30AM -0400, why the lucky stiff wrote: | Can anyone direct me to a succinct explanation of why this must change? | I love having two types of scalars, it has never been a wart to me. To answer _why's question; it doesn't. The driving reason for this is that we've said in the spec that style is "presentation only" but then we have this exception. To some people this seems inconsistent, and, know what? Being inconsistent is fun. Does everyone here agree that this exception should _only_ apply to the plain scalar? If not, speak up! This debate has raged on and on, but I'd like to forever point back to this last week if someone brings it up again. ... So, in this case, we are back with essentially working out _how_ we are going to report this difference. The previous two options are: - We report four ?tags to the application, ?mapping, ?sequence, ?scalar-plain, ?scalar-other. - We report three NULL tags to the application for the untagged mapping, sequence, and plain scalar. The non-plain scalars are reported as tag:yaml.org,2002:str There is another permutation (just moving the wart around): - We report three NULL tags to the application for the untagged mapping, sequence, and non-plain scalar. The plain scalar is reported using the ! tag. The primary advantage of the latter one is that you can choose to only use double-quoted strings (necessary for my canonical form use case), since these two are equivalent: - 23 - ! "23" So, in effect, a plain scalar becomes syntax-short-hand for using a ! private type. Of course, this will cause Oren to have cats since he wants the untagged nodes to be NULL. This will also put the ! vs !! item to rest, since for this to be even somewhat consistent ! has to be a private (indeterminate) tag. So, of the three, I think this last one is probably the best home for the wart. Any other options? This debate is getting quite _old_ no? Cheers! Clark |
From: Oren Ben-K. <or...@be...> - 2004-09-13 06:43:04
|
On Monday 13 September 2004 09:33, Clark C. Evans wrote: > This debate is getting quite _old_ no? Like guests and fish, debates start to smell after a few days. I think we have said everything - nobody has come up with a new point for the last few days, its just that everyone rehases the fact he has a different relative importance to each old point. Fine, that's life. We came up with something nobody is too unhappy with. Let's move on. Have fun, Oren Ben-Kiki |
From: why t. l. s. <yam...@wh...> - 2004-09-13 06:49:51
|
Clark C. Evans wrote: > > To answer _why's question; it doesn't. The driving reason for this > is that we've said in the spec that style is "presentation only" but > then we have this exception. To some people this seems > inconsistent, and, know what? Being inconsistent is fun. > I'm voting against, but it's cool if it changes. I don't want to interfere with Oren's ideals. It seems like an ounce of sugar to me and YAML tastes a bit cardboard without it. I think it's probably less useful outside of Ruby. _why |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-13 06:54:27
|
On Monday 13 September 2004 02:33 am, Clark C. Evans wrote: > Does everyone here agree that this exception should _only_ apply to > the plain scalar? If not, speak up! This debate has raged on and > on, but I'd like to forever point back to this last week if someone > brings it up again. There's also the multiple !plain, !quoted, !literal, !folded possibility. But I can't say that's really any better. More like four warts for the price of one. (Albeit the spec is still simplified some.) So the answer for me is No. Besides I got better idears.... > ... > > So, in this case, we are back with essentially working out _how_ we > are going to report this difference. Damn, you too? > The previous two options are: > > - We report four ?tags to the application, ?mapping, ?sequence, > ?scalar-plain, ?scalar-other. Either this with: ?map, ?seq, ?sym, ?str > - We report three NULL tags to the application for the untagged > mapping, sequence, and plain scalar. The non-plain scalars > are reported as tag:yaml.org,2002:str No, better. Have _four kinds_. the all tags can be NULL. The kinds are mapping, sequence, string, symbol (the last two being the two fundamental types of scalars) > There is another permutation (just moving the wart around): > > - We report three NULL tags to the application for the untagged > mapping, sequence, and non-plain scalar. The plain scalar > is reported using the ! tag. > > The primary advantage of the latter one is that you can choose to > only use double-quoted strings (necessary for my canonical form use > case), since these two are equivalent: > > - 23 > - ! "23" > > So, in effect, a plain scalar becomes syntax-short-hand for using a > ! private type. Of course, this will cause Oren to have cats since > he wants the untagged nodes to be NULL. This will also put the ! vs > !! item to rest, since for this to be even somewhat consistent ! has > to be a private (indeterminate) tag. So, of the three, I think this > last one is probably the best home for the wart. Any other options? > This debate is getting quite _old_ no? Either we'll be having a birthday party or a bon voyage party for this damn wart soon! :-) T. -- ( o _ // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. -Mark Twain |
From: Clark C. E. <cc...@cl...> - 2004-09-13 07:07:03
|
On Mon, Sep 13, 2004 at 02:54:23AM -0400, trans. (T. Onoma) wrote: | > The previous two options are: | > | > - We report four ?tags to the application, ?mapping, ?sequence, | > ?scalar-plain, ?scalar-other. | | Either this with: ?map, ?seq, ?sym, ?str Well, in any case, we still need to provide the quoted style for these ?sym objects. So, some way to flag the quoted style that it is a ?sym would be needed. "quoted" -> ?str ! "quoted" -> ?sym Its icky, but the only clear option I see. If we just make ?sym a ?str with a tag of ! it is the same as above, and we don't need the extra ?thingy. So I still prefer the latter option, 23 = ! "23" ;) | No, better. Have _four kinds_. the all tags can be NULL. The | kinds are mapping, sequence, string, symbol (the last two | being the two fundamental types of scalars) I also prefer NULL; but I don't see a fundamental difference in 'string' and 'symbol', they can both be typed !!int correct? | > - We report three NULL tags to the application for the untagged | > mapping, sequence, and non-plain scalar. The plain scalar | > is reported using the ! tag. | > | > The primary advantage of the latter one is that you can choose to | > only use double-quoted strings (necessary for my canonical form use | > case), since these two are equivalent: | > | > - 23 | > - ! "23" | > | > So, in effect, a plain scalar becomes syntax-short-hand for using a | > ! private type. Of course, this will cause Oren to have cats since | > he wants the untagged nodes to be NULL. |
From: Damian C. <dam...@gm...> - 2004-09-13 11:22:56
|
On Mon, 13 Sep 2004 03:07:01 -0400, Clark C. Evans <cc...@cl...> wrote: > Well, in any case, we still need to provide the quoted style for > these ?sym objects. So, some way to flag the quoted style that it > is a ?sym would be needed. > > "quoted" -> ?str > ! "quoted" -> ?sym > > Its icky, but the only clear option I see. I'm confused. Why do we need a special syntax that says 'Even though I have quoted this value, treat it as if I had not', when the simpler option would surely be to not quote it in the first place? If your emitter is too dumb to know not to quote integers, then I imagine it is also too dumb to add the ignore-these-quotes marker... -- Damian -- Damian Cugley, Alleged Literature http://www.alleged.org.uk/pdc/ |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-13 04:40:06
|
On Sunday 12 September 2004 10:44 pm, Clark C. Evans wrote: > - > =A0 issue: "23" and 23 are parsed the same > =A0 note: this has not yet been approved by Brian > =A0 reason: > =A0 =A0 plain style flag is no longer reported to appliction > =A0 solution: > =A0 =A0 - if the document has either of the above two items, > =A0 =A0 =A0 it is clearly a 1.0 document, and backward-compatible > =A0 =A0 =A0 behavior is possible > =A0 =A0 - if the document contains %YAML 1.1 directive, then > =A0 =A0 =A0 it is clearly 1.1 document, and the distinction can > =A0 =A0 =A0 be safely ignored > =A0 =A0 - in YAML 1.1, there really isn't a need to use the > =A0 =A0 =A0 double-quoted "23", so all other cases should ignore > =A0 =A0 =A0 the distinction, but issue a warning; and perhaps > =A0 =A0 =A0 install a parser option This is the one I find hardest to swallow. I am so used to writing 23 for a= n=20 integer and '23' or "23" for a string. Now I have to write !! 23 (or ! 23) = to=20 get a string. Clark, are you sure we want to do _THIS_? =2D-=20 ( o _ // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. =2DMark Twain |
From: Tim P. <ti...@po...> - 2004-09-13 07:53:02
|
On Mon, 2004-09-13 at 05:40, trans. (T. Onoma) wrote: > On Sunday 12 September 2004 10:44 pm, Clark C. Evans wrote: > > - > > issue: "23" and 23 are parsed the same > > note: this has not yet been approved by Brian > > reason: > > plain style flag is no longer reported to appliction >=20 > This is the one I find hardest to swallow. I am so used to writing 23 for= an=20 > integer and '23' or "23" for a string. Now I have to write !! 23 (or ! 23= ) to=20 > get a string. Just my two cents... 23 and '23' are the same!! implicit typing is optional and hence returned type should be consistent. Tim |
From: Clark C. E. <cc...@cl...> - 2004-09-13 15:12:32
|
On Mon, Sep 13, 2004 at 08:52:49AM +0100, Tim Parkin wrote: | On Mon, 2004-09-13 at 05:40, trans. (T. Onoma) wrote: | > > issue: "23" and 23 are parsed the same | > | > This is the one I find hardest to swallow. | | Just my two cents... 23 and '23' are the same!! implicit typing is | optional and hence returned type should be consistent. I'm sorry if I was not absolutely clear, what we are talking about is if 23 and '23' are reported the same or different going _into_ the implicit typing phase. How they come out, is well, Application dependent. The details of how they go in (identically, or distinguished via ?imp or ! tags ) are largely equivalent. Cheers! Clark |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-13 04:59:09
|
On Sunday 12 September 2004 10:44 pm, Clark C. Evans wrote: > After this conversation, I got to thinking a bit about the last > item, swapping "!" and "!!". =A0My friend went so far to say that it > was a 'fine decision', and was not convinced by our rationale to > change it. As a side note, if we didn't swap their meaning we keep > backwards compatibility with PyYaml, and also, we can explicitly > type something a string by using ! 23 =A0instead of !! 23. =A0So. =A0Do we > really want to swap ! and !! -- anyone care to chime in? It's a trade off again either way: ! / !! ! / !! local/yaml vs. yaml/local Compatability +1 -1 Global Consistency -1 +1 Brevity +.5 0 Local gets brevity b/c when you do use locals, you tend to use them much mo= re=20 than YAML's. Vice-versa it's not the case. =2D-=20 ( o _ // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. =2DMark Twain |
From: David H. <dav...@bl...> - 2004-09-13 10:29:50
|
trans. (T. Onoma) wrote: > It's a trade off again either way: > > ! / !! ! / !! > local/yaml vs. yaml/local > Compatability +1 -1 > Global Consistency -1 +1 > Brevity +.5 0 I don't see what the "global consistency" argument is referring to. For me it would be: ! / !! ! / !! local/yaml vs. yaml/local Compatability +1 -1 Brevity for YAML types -0.1 +0.1 Brevity for local types +0.1 -0.1 -- David Hopwood <dav...@bl...> |
From: David H. <dav...@bl...> - 2004-09-13 10:50:06
|
David Hopwood wrote: > trans. (T. Onoma) wrote: > >> It's a trade off again either way: >> >> ! / !! ! / !! >> local/yaml vs. yaml/local >> Compatability +1 -1 >> Global Consistency -1 +1 >> Brevity +.5 0 > > I don't see what the "global consistency" argument is referring to. For > me it would be: > > ! / !! ! / !! > local/yaml vs. yaml/local > Compatability +1 -1 > Brevity for YAML types -0.1 +0.1 > Brevity for local types +0.1 -0.1 ... with the Compatibility columns reversed. -- David Hopwood <dav...@bl...> |
From: Oren Ben-K. <or...@be...> - 2004-09-13 05:09:01
|
On Monday 13 September 2004 07:58, trans. (T. Onoma) wrote: > It's a trade off again either way: > > ! / !! ! / !! > local/yaml vs. yaml/local > Compatability +1 -1 Don't you mean: Compatability -1 +1 Actually given Perl serialization files, it might be more like: Compatability -1 +0.5 > Global Consistency -1 +1 I'm not certain what you mean. Both options seem consistent to me... Global Consistency +1 +1 > Brevity +.5 0 > Local gets brevity b/c when you do use locals, you tend to use them > much more than YAML's. Vice-versa it's not the case. I suppose so. It comes up as a tie :-) Have fun, Oren Ben-Kiki |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-13 05:20:33
|
On Monday 13 September 2004 01:08 am, Oren Ben-Kiki wrote: > On Monday 13 September 2004 07:58, trans. (T. Onoma) wrote: > > It's a trade off again either way: > > > > ! / !! ! / !! > > local/yaml vs. yaml/local > > Compatability +1 -1 > > Don't you mean: > Compatability -1 +1 Oops! stop. reverse that ;) > Actually given Perl serialization files, it might be more like: > Compatability -1 +0.5 > > > Global Consistency -1 +1 > > I'm not certain what you mean. Both options seem consistent to me... > Global Consistency +1 +1 That !! is a empty handle, so it implies global, which ! imples local (although it can be globalized). So a little to the left. > > Brevity +.5 0 > > Local gets brevity b/c when you do use locals, you tend to use them > > much more than YAML's. Vice-versa it's not the case. > > I suppose so. Alas, why are we doing this to ourselves.... -- ( o _ // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. -Mark Twain |
From: Oren Ben-K. <or...@be...> - 2004-09-13 06:39:32
|
On Monday 13 September 2004 08:20, trans. (T. Onoma) wrote: > Alas, why are we doing this to ourselves.... Agreed. The two ways are roughly equivalent, so while I would slightly prefer to use !! for private tags and ! for global tags, since Brian feels strongly the other way around, that's good enough for me. !! for global and ! for private it is, and lets stop wasting our breath on it. Nobody said anything new about it in days anyway :-) Have fun, Oren Ben-Kiki |