From: trans. (T. Onoma) <tra...@ru...> - 2004-09-10 04:24:01
|
Assertion: The primary patterns of scalar presentation are inextricably related to scalar representation. Evidence: - Special implicit treatment of plain-scalar ("the wart") - A map key may be valid as presented, but may resolve into a duplication - Style of emitted scalars should certainly be able to be based on type Conclusion Allow the primary categories of scalar style to be used in resolution. Benefits: - Wart goes away - Native types can be assigned scalar style. Emitting works seemlessly. - Brian's principle of "Application is in control" is upheld. - Onoma's corollary "Semantics belongs to the application" is too. - Sean's (b) proposal is reasonable / All scalars are uniformly treated. - Oren's NULL tags are too / No special types are required. -- ( o //\ trans. / \ tra...@ru... I ain't give a dam for nobody that can only spells hiz words just wun way. -Mark Twain, paraspelled ;) |
From: Clark C. E. <cc...@cl...> - 2004-09-10 13:38:58
|
Perhaps Sean's idea (absolish special treatment of plain scalars) may be worth it. On Fri, Sep 10, 2004 at 12:23:57AM -0400, trans. (T. Onoma) wrote: | The primary patterns of scalar presentation are inextricably related | to scalar representation. Na, you're taking an exception and turning it into a rule. | - Special implicit treatment of plain-scalar ("the wart") | - A map key may be valid as presented, but may resolve into a duplication These two are indeed symptoms of the plain-scalar exception. | - Style of emitted scalars should certainly be able to be based on type This one is dumb. You could argue that your data should be dependent upon just about anything in the serialization in this case, including comments, where line breaks are in a folded scalar, or even indentation. If this is true, what you've got is an "Editor" which should us the Presentation Model for its data; but don't expect it to play nicely with other YAML Applications. | Conclusion | Allow the primary categories of scalar style to be used in resolution. I've got an alternative conclusion based on Steve's suggestion; totally abolish the plain-scalar exception, in other words "23" is reported by the parser in the same way as 23. Let's go through the arguments: Q: But... like I was happy specifying a (your data type) implicitly! A: You can still do that. A few options: - Run regex on each incoming scalar, if it matches a regex for your type, make it into that type. - If someone wants to override this, they can just use !!str or some other type to force it to be a string or what not. - Nothing stopping you from inventing your own implicit mechanism layered on-top of YAML's system. Q: But that's not implicit! There are several characters which are not indicators that can be used to start plain scalars: = ~ + < $ ^ ( ) _ ; / \ - For numbers, make your regex start with "-34" or "+34" and such; it would be highly unusual for a string to start with a plus sign, and in that case, the user can !!tag it explicitly. - For Null, make your string be '~', for Booleans, '~True' and '~False' - Make dates start with a hat ^ Really. Get creative. There's not any reason for this black-magic to be so low-level in YAML. Make your implicit mechanism triggered by parenthesis: - (34) # number - (3002-10-23) # date - (true) # boolean - (null) # null value Get creative. If you user wants to be explicit, they can. | Benefits: | - Wart goes away yep | - Native types can be assigned scalar style. Emitting works seemlessly. this nightmare is completely avoided | - Brian's principle of "Application is in control" is upheld. true | - Onoma's corollary "Semantics belongs to the application" is too. also true | - Sean's (b) proposal is reasonable / All scalars are uniformly treated. true | - Oren's NULL tags are too / No special types are required. sure; it makes 3 default styles. So, what do you say? Let the application invent its own way to flag implicit scalars? Clark |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-10 13:50:55
|
On Friday 10 September 2004 09:35 am, you wrote: > This one is dumb. =A0You could argue that your data should be dependent > upon just about anything in the serialization in this case, including > comments, where line breaks are in a folded scalar, or even indentation. > If this is true, what you've got is an "Editor" which should us the > Presentation Model for its data; but don't expect it to play nicely with > other YAML Applications. =46unny you should say that this is dumb, b/c my document sure looks dumb w= hen=20 it runs into this problem: art: | hello_world_3 +--------------------------------+ | hello_text | +--------------------------------+ | "Your Name:" [your_name] | +--------------------------------+ Is being emitted as: art: > hello_world_3 +--------------------------------+ | hello_text | +--------------------------------+ | "Your Name:" [your_name] | +--------------------------------+ =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: Clark C. E. <cc...@cl...> - 2004-09-10 15:37:14
|
On Fri, Sep 10, 2004 at 09:47:44AM -0400, trans. (T. Onoma) wrote: | art: | | | hello_world_3 | +--------------------------------+ | | hello_text | | +--------------------------------+ | | "Your Name:" [your_name] | | +--------------------------------+ | | Is being emitted as: | | art: > | | hello_world_3 | | +--------------------------------+ | | | hello_text | | | +--------------------------------+ | | | "Your Name:" [your_name] | | | +--------------------------------+ This is an emitter issue; you should be able to 'suggest' formatting hints. Clark |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-10 14:15:00
|
On Friday 10 September 2004 09:35 am, Clark C. Evans wrote: > =A0 =A0 =A0Get creative. =A0If you user wants to be explicit, they can. > =A0 =A0 =A0 > | Benefits: > | =A0 - Wart goes away > yep > | =A0 - Native types can be assigned scalar style. Emitting works seemles= sly. > this nightmare is completely avoided > | =A0 - Brian's principle of "Application is in control" is upheld. > true > | =A0 - Onoma's corollary "Semantics belongs to the application" is too. > also true > | =A0 - Sean's (b) proposal is reasonable / All scalars are uniformly > | treated. > true > | =A0 - Oren's NULL tags are too / No special types are required. > sure; it makes 3 default styles. > > So, what do you say? =A0Let the application invent its own way to flag > implicit scalars? You're right Clark, that is the other "reasonable boundary". But you know a= s=20 well as I, this solution is unacceptable -- if it were, you would have neve= r=20 had the plain-scalar wart to begin with. BTW - Your examples of how the applications could do their own "creative"=20 implicits is _dumber_ :p ;) =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: Clark C. E. <cc...@cl...> - 2004-09-10 15:37:06
|
On Fri, Sep 10, 2004 at 10:13:27AM -0400, trans. (T. Onoma) wrote: | You're right Clark, that is the other "reasonable boundary". But you know | as well as I, this solution is unacceptable -- if it were, you would have | never had the plain-scalar wart to begin with. Well this isn't cut and dry, we had many options and the current compromise was done with what we had a the time. I think the most important consideration is that we didn't have the idea of a 'null' tag, i.e. ?scalar, thus, if the application wanted to do implicit typing by default, there was no standard way to turn it off. --- - 23 # ?scalar "23" - "23" # ?scalar "23" - !!str 23 # tag:yaml.org,2002:str "23 ... Now this isn't so bad. An application can apply implicit typing to those marked ?scalar. This wasn't possible (before) without using implicit types. Also, Perl doesn't have integers, it has 'scalars', so as I remember, Brian was arguing _against_ implicit typing and the plain scalar. Now that I've been using YAML for 2 years... I'm really not sure that implicit typing is all that important. All of my applications _know_ what scalars are integers, dates, and what not. You don't have to tell me in the serialization. In fact, I've got much more specific types, so I end up having a "transform" phase right afer load where I go though and fix-up the serialization doing stuff like: - adding missing, aka 'default' mapping keys - verifying that I recognize all mapping keys - converting dates into the correct format (I allow quite a few date formats) - lots and lots of other stuff So, it's not like the plain scalar is helping me, they arn't helping Brian, I think. I actually have been turning off implicit typing. Best, Clark |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-10 17:51:36
|
On Friday 10 September 2004 09:35 am, Clark C. Evans wrote: > This one is dumb. =A0You could argue that your data should be dependent > upon just about anything in the serialization in this case, including > comments, where line breaks are in a folded scalar, or even indentation. > If this is true, what you've got is an "Editor" which should us the > Presentation Model for its data; but don't expect it to play nicely with > other YAML Applications. Oh, and you're extrapolating. I'm talking about the _primary_ distinction=20 between scalars. _Not_=20 "just about anything in the serialization in this case, including comments, where line breaks are in a folded scalar, or even indentation." =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: Brian I. <in...@tt...> - 2004-09-10 14:39:11
|
On 10/09/04 00:23 -0400, trans. (T. Onoma) wrote: > > Assertion: > > The primary patterns of scalar presentation are inextricably related > to scalar representation. > > Evidence: > > - Special implicit treatment of plain-scalar ("the wart") > > - A map key may be valid as presented, but may resolve into a duplication > > - Style of emitted scalars should certainly be able to be based on type > > Conclusion > > Allow the primary categories of scalar style to be used in resolution. > > Benefits: > > - Wart goes away > > - Native types can be assigned scalar style. Emitting works seemlessly. > > - Brian's principle of "Application is in control" is upheld. > > - Onoma's corollary "Semantics belongs to the application" is too. > > - Sean's (b) proposal is reasonable / All scalars are uniformly treated. > > - Oren's NULL tags are too / No special types are required. Hmmm. I think Onama might be on to something. It really makes sense for a parser to report the style used and here is why: "Simply because it makes sense for an emitter to have the preferred style passed to it." One simple rule to apply to our strawmen is that "everything that the parser does, the emitter must do in reverse". In the case where you are creating a simple YAML filter, you aren't loading anything, you are simply sitting in the middle of streaming events from a parser to an emitter. You almost certainly want the parser to pass on style info so the emitter can emit something fairly close to the original. You don't want the emitter to have to guess on each node. So if an emitter takes a scalar style, it is fair to say that its matching parser must produce style info. If this is the case, why not just use style as a part of tag resolution and skip the whole ?str vs ?var thing? Cheers, Brian |
From: Clark C. E. <cc...@cl...> - 2004-09-10 15:00:33
|
Brian, Thanks for weighing-in. On Thu, Sep 09, 2004 at 10:19:59PM -0700, Brian Ingerson wrote: | It really makes sense for a parser to report the style used and here is | why: "Simply because it makes sense for an emitter to have the preferred | style passed to it." You use the word 'preferred' here. Very important. | One simple rule to apply to our strawmen is that "everything that the | parser does, the emitter must do in reverse". I have no problem with the parser "reporting" styles, comments, or any other presentation-level information. Just like I have no problem with the emitter "accepting" this information. I'd rather not _require_ a parser to report this information though, just like an emitter shouldn't be required to take this information. | In the case where you are creating a simple YAML filter, you aren't | loading anything, you are simply sitting in the middle of streaming | events from a parser to an emitter. You almost certainly want the parser | to pass on style info so the emitter can emit something fairly close to | the original. You don't want the emitter to have to guess on each node. That's fine. And a simple emitter could "guess" by making everything be double quoted if an application didn't provide "presentation hints". | So if an emitter takes a scalar style, it is fair to say that its | matching parser must produce style info. Once again, no problem. I fully agreee up-to this point. | If this is the case, why not just use style as | a part of tag resolution and skip the whole ?str vs ?var thing? Beacuse it makes 'style' informational. In effect, it prevents a "Pretty Printer" for YAML data. If one changes the style, and it _could_ cause the application to change its behavior, you are effectively forbidden from doing all of these nice presentation level things. XML has this "feature", the result is that each application has its own idea about what is significant and what isn't. The result is ugly, editors can't help the user with making the XML look nice. It has to preserve things _exactly_ as it sees them. This, IMHO, sucks. We want authors of YAML to have freedom to choose how they want their stuff to look -- we want YAML to be pretty. Perhaps Sean is right -- consistency is more important than having people be able to use a ill-defined implicit-typing mechanism. At the low-levels of YAML, things should just be scalars, mappings, and sequences. Let the application impose its own implict typing at a higher level. Cheers! Clark |
From: Sean O'D. <se...@ce...> - 2004-09-10 18:11:17
|
On Friday 10 September 2004 09:58, trans. (T. Onoma) wrote: > > > Perhaps Sean is right -- consistency is more important than having > > people be able to use a ill-defined implicit-typing mechanism. At the > > low-levels of YAML, things should just be scalars, mappings, and > > sequences. Let the application impose its own implict typing at a > > higher level. > > The effect of this is to necessitate the use of a schema --be it purely in > app code or otherwise, severely damaging YAML's usefullness as simple > config files. The loader could certainly still perform implicit typing, but it would do so in a more uniform way, at a certain point. It wouldn't affect YAML's usefulness in that regard. I don't think Clark meant to abolish all implicit typing, just to relegate it to an end-of-the-rainbow area where schemas live. An implementation could *certainly* provide it's own built-in scheme for typing nodes. Syck would use the same exact code and conditions it uses right now for that, just in a more consistent way. It wouldn't affect you as a YAML user at all. Sean O'Dell |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-10 17:55:34
|
On Friday 10 September 2004 01:34 pm, you wrote: > The loader could certainly still perform implicit typing, but it would do > so in a more uniform way, at a certain point. It wouldn't affect YAML's > usefulness in that regard. I don't think Clark meant to abolish all > implicit typing, just to relegate it to an end-of-the-rainbow area where > schemas live. An implementation could *certainly* provide it's own built-in > scheme for typing nodes. Syck would use the same exact code and conditions > it uses right now for that, just in a more consistent way. It wouldn't > affect you as a YAML user at all. Yes, it would, Sean. --- - "23" Would come back an integer. How would it know the difference? I'm not about to write a schema for that! You know, I embed scraps of YAML in my code too. Its not always a fancy external doc. -- ( o _ // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. -Mark Twain |
From: Sean O'D. <se...@ce...> - 2004-09-10 18:10:41
|
On Friday 10 September 2004 10:55, trans. (T. Onoma) wrote: > On Friday 10 September 2004 01:34 pm, you wrote: > > The loader could certainly still perform implicit typing, but it would do > > so in a more uniform way, at a certain point. It wouldn't affect YAML's > > usefulness in that regard. I don't think Clark meant to abolish all > > implicit typing, just to relegate it to an end-of-the-rainbow area where > > schemas live. An implementation could *certainly* provide it's own > > built-in scheme for typing nodes. Syck would use the same exact code and > > conditions it uses right now for that, just in a more consistent way. It > > wouldn't affect you as a YAML user at all. > > Yes, it would, Sean. > > --- > - "23" > > Would come back an integer. How would it know the difference? I'm not about > to write a schema for that! It doesn't have to. There are two ways to approach this, remember option a and b I gave? The scalar could be initially tagged as !!scalar and left *with* the quotes until the *single* implicit typing phase, where the quotes are seen, the node changed to !!str and the quotes removed. "23" would be loaded as a string. I'm not advocating strongly for either option, although clearly I think you have a good point, so the way I describe above is the only real possibility. Regardless, the point I'm after is: getting implicit typing moved into one phase. Sean O'Dell |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-10 21:44:28
|
On Friday 10 September 2004 11:00 am, you wrote: > Brian, > > Thanks for weighing-in. > > On Thu, Sep 09, 2004 at 10:19:59PM -0700, Brian Ingerson wrote: > | It really makes sense for a parser to report the style used and here is > | why: "Simply because it makes sense for an emitter to have the preferred > | style passed to it." > > You use the word 'preferred' here. Very important. "Preferred" as in the application can change it. _Not_ as in the application _must_ deal with it, which your solution forces one to do (e.g. setting hints). > | If this is the case, why not just use style as > | a part of tag resolution and skip the whole ?str vs ?var thing? > > Beacuse it makes 'style' informational. In effect, it prevents a > "Pretty Printer" for YAML data. If one changes the style, and it > _could_ cause the application to change its behavior, you are > effectively forbidden from doing all of these nice presentation level > things. XML has this "feature", the result is that each application has > its own idea about what is significant and what isn't. The result is > ugly, editors can't help the user with making the XML look nice. It has > to preserve things _exactly_ as it sees them. This, IMHO, sucks. We > want authors of YAML to have freedom to choose how they want their stuff > to look -- we want YAML to be pretty. Default behavior would be the same --it would not prevent PP. Only if the application explicitly requested transformations based on style would anything change. In such applications PP wouldn't be useful anyway. Pretty is relative to the task. Forcing an app to use tags on common scalars, or worse using "creative" implicits, isn't pretty. I certainly don't mind a strong recommendation in the spec for steering clear of using style in transformations. Believe me, I am not unsympathetic to your concerns. But forcing my application into "creative" tricks when such functionality is needed, is not helpful. Besides it makes round-tripping much more elegant. > Perhaps Sean is right -- consistency is more important than having > people be able to use a ill-defined implicit-typing mechanism. At the > low-levels of YAML, things should just be scalars, mappings, and > sequences. Let the application impose its own implict typing at a > higher level. The effect of this is to necessitate the use of a schema --be it purely in app code or otherwise, severely damaging YAML's usefullness as simple config files. A better compromise might be that locals can transformed based on style, but global's cannot. But, that seems rather arbitrary. -- ( o _ // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. -Mark Twain |
From: trans. (T. Onoma) <tra...@ru...> - 2004-09-11 03:19:29
|
** NOTE THIS MAY COME ACROSS TWICE. THE MAIL SERVER IS REALLY SLOW!!! ** On Friday 10 September 2004 11:00 am, you wrote: > Brian, > > Thanks for weighing-in. > > On Thu, Sep 09, 2004 at 10:19:59PM -0700, Brian Ingerson wrote: > | It really makes sense for a parser to report the style used and here is > | why: "Simply because it makes sense for an emitter to have the preferred > | style passed to it." > > You use the word 'preferred' here. Very important. "Preferred" as in the application can change it. _Not_ as in the application _must_ deal with it, which your solution forces one to do (e.g. setting hints). > | If this is the case, why not just use style as > | a part of tag resolution and skip the whole ?str vs ?var thing? > > Beacuse it makes 'style' informational. In effect, it prevents a > "Pretty Printer" for YAML data. If one changes the style, and it > _could_ cause the application to change its behavior, you are > effectively forbidden from doing all of these nice presentation level > things. XML has this "feature", the result is that each application has > its own idea about what is significant and what isn't. The result is > ugly, editors can't help the user with making the XML look nice. It has > to preserve things _exactly_ as it sees them. This, IMHO, sucks. We > want authors of YAML to have freedom to choose how they want their stuff > to look -- we want YAML to be pretty. Default behavior would be the same --it would not prevent PP. Only if the application explicitly requested transformations based on style would anything change. In such applications PP wouldn't be useful anyway. Pretty is relative to the task. Forcing an app to use tags on common scalars, or worse using "creative" implicits, isn't pretty. I certainly don't mind a strong recommendation in the spec for steering clear of using style in transformations. Believe me, I am not unsympathetic to your concerns. But forcing my application into "creative" tricks when such functionality is needed, is not helpful. Besides it makes round-tripping much more elegant. > Perhaps Sean is right -- consistency is more important than having > people be able to use a ill-defined implicit-typing mechanism. At the > low-levels of YAML, things should just be scalars, mappings, and > sequences. Let the application impose its own implict typing at a > higher level. The effect of this is to necessitate the use of a schema --be it purely in app code or otherwise, severely damaging YAML's usefullness as simple config files. A better compromise might be that locals can transformed based on style, but global's cannot. But, that seems rather arbitrary. -- ( o _ // trans. / \ tra...@ru... I don't give a damn for a man that can only spell a word one way. -Mark Twain |
From: Sean O'D. <se...@ce...> - 2004-09-10 15:54:39
|
On Thursday 09 September 2004 22:19, Brian Ingerson wrote: > > One simple rule to apply to our strawmen is that "everything that the > parser does, the emitter must do in reverse". > > In the case where you are creating a simple YAML filter, you aren't > loading anything, you are simply sitting in the middle of streaming > events from a parser to an emitter. You almost certainly want the parser > to pass on style info so the emitter can emit something fairly close to > the original. You don't want the emitter to have to guess on each node. > > So if an emitter takes a scalar style, it is fair to say that its matching > parser must produce style info. If this is the case, why not just use style > as a part of tag resolution and skip the whole ?str vs ?var thing? When it comes to folded styles, I think of course the styles should be noted. But when it comes to character escapes, I seriously doubt the emitter can emit *precisely* what was loaded. There may be several ways to escape a special character, and it will be loaded as the special character, then re-escaped when re-emitted, but how does the emitter decide which escape mechanism to use? It will simply have to choose a default. Outer quotes may be lost, but then, if you think about it, if outer quotes were meant to be part of the data and not an escape mechanism, they themselves should have been escaped, i.e.: \"node value with quotes\". Sean O'Dell |
From: Clark C. E. <cc...@cl...> - 2004-09-10 16:26:20
|
On Fri, Sep 10, 2004 at 08:47:38AM -0700, Sean O'Dell wrote: | > So if an emitter takes a scalar style, it is fair to say that its | > matching parser must produce style info. If this is the case, why | > not just use style as a part of tag resolution and skip the | > whole ?str vs ?var thing? | | When it comes to folded styles, I think of course the styles should | be noted. The question isn't "may the styles be reported" (sorry for framing the problem incorrectly). Brian answered the first question, Yes, and there isn't a debate here. Of course it _can_ be reported by the parser... in a presentation level interface, along with comments, and every other presentation detail. The question is "should type be determined by style?" And right now, YAML says "no, except the plain scalar". This seems to violate people's sense of consistency. You had proposed earlier (unless I mis-understood) that the answer should be "no", and T.Onoma was proposing "yes". I'm now sick of this debate; and if saying "NO" will make it permanently go away, then I'm all for it. I was ok to allow an exception, however, it seems the exception isn't strictly needed and it also seems to be causing more confusion (and chatter) than it is worth. Also, after two years of using YAML, I've found the feature to be more painful than helpful, on average, and since the mechanism isn't strong enough for what I need -- I ended up rolling my own anyway. So, I'm very happy to let the 'exception' go away in YAML 1.1 | But when it comes to character escapes, I seriously doubt the emitter can | emit *precisely* what was loaded. There may be several ways to escape a | special character, and it will be loaded as the special character, then | re-escaped when re-emitted, but how does the emitter decide which escape | mechanism to use? It will simply have to choose a default. Outer | quotes may be lost, but then, if you think about it, if outer quotes | were meant to be part of the data and not an escape mechanism, they | themselves should have been escaped, i.e.: \"node value with quotes\". which is why, BTW, we have the single quote style: '"node value with quotes"' But, if style _could_ be used by an application to determine type, then all justifcation we have for various styles is completely gone. Clark |
From: Sean O'D. <se...@ce...> - 2004-09-10 16:43:37
|
On Friday 10 September 2004 09:25, Clark C. Evans wrote: > > The question is "should type be determined by style?" And right now, > YAML says "no, except the plain scalar". This seems to violate people's > sense of consistency. You had proposed earlier (unless I mis-understood) > that the answer should be "no", and T.Onoma was proposing "yes". A titanic NO here also, please. Style should determine !!map, !!seq or !!scalar (or however it's denoted), but I don't think anything else. The implicit typing phase should be one single pass that tags nodes based on their values, with the leftovers remaining either !!scalar or becoming !!str. Sean O'Dell |
From: Clark C. E. <cc...@cl...> - 2004-09-10 17:28:16
|
On Fri, Sep 10, 2004 at 12:58:42PM -0400, trans. (T. Onoma) wrote: | > If one changes the style, and it | > _could_ cause the application to change its behavior, you are | > effectively forbidden from doing all of these nice presentation level | > things. | | Default behavior would be the same --it would not prevent PP. Only if the | application explicitly requested transformations based on style would | anything change. In such applications PP wouldn't be useful anyway. | Pretty is relative to the task. Forcing an app to use tags on common | scalars, or worse using "creative" implicits, isn't pretty. If an application _can_ change the type based on formatting information, then all bets of a generic pretty printer are off. This is the case that XML has. You can't indent tags, for instance, unless you really know that the application does not use whitespace in a signficiant way. | I certainly don't mind a strong recommendation in the spec for steering | clear of using style in transformations. Believe me, I am not | unsympathetic to your concerns. But forcing my application into | "creative" tricks when such functionality is needed, is not helpful. | Besides it makes round-tripping much more elegant. If your application is an 'Editor' where style like this matters, the Specfication places no such limits on you. You are using the Presentation Model. | > Perhaps Sean is right -- consistency is more important than having | > people be able to use a ill-defined implicit-typing mechanism. At the | > low-levels of YAML, things should just be scalars, mappings, and | > sequences. Let the application impose its own implict typing at a | > higher level. | | The effect of this is to necessitate the use of a schema --be it | purely in app code or otherwise, severely damaging YAML's usefullness | as simple config files. If you have implicit typing at _any_ level you need a schema. Best, Clark -- Clark C. Evans Prometheus Research, LLC. http://www.prometheusresearch.com/ o office: +1.203.777.2550 ~/ , mobile: +1.203.444.0557 // (( Prometheus Research: Transforming Data Into Knowledge \\ , \/ - Research Exchange Database /\ - Survey & Assessment Technologies ` \ - Software Tools for Researchers ~ * |
From: Sean O'D. <se...@ce...> - 2004-09-10 15:54:39
|
On Friday 10 September 2004 06:35, Clark C. Evans wrote: <snip> > > Get creative. If you user wants to be explicit, they can. <snip> > So, what do you say? Let the application invent its own way to flag > implicit scalars? Or better yet, since the built-in YAML implicit typing would be a single step, it would be very simple for the application to hook into the loader and ask for certain nodes to be typed. If implicit typing is a single phase, it's very easy to see how the current mechanism could be replaced by a schema, so it's pretty open from there how an implementation would allow hooks in. Perhaps the application could supply its own schema, or modify the default one, or just make a request using some interface native to the implementation. Sean O'Dell |
From: Tim H. <tim...@co...> - 2004-09-10 17:02:26
|
Sean O'Dell wrote: >On Friday 10 September 2004 09:08, Clark C. Evans wrote: > > >>On Fri, Sep 10, 2004 at 08:41:03AM -0700, Sean O'Dell wrote: >>| Or better yet, since the built-in YAML implicit typing would be a single >>| step, it would be very simple for the application to hook into the >>| loader and ask for certain nodes to be typed. >> >>Are you still advocating that even during this phase, that the >>following would be reported in the same way: >> >> - "32" >> - 32 >> >> > >Definitely. Actually, I'd like them to be sent to loader the same way, both >as scalars with just 32 as the value, since the quotes would be stripped away >by the escape mechanism. They're then equal getting to the loader, which >would implicitly type them both the same as !!int. > > <unlurk> Ugh. Please not this. I can see the appeal of the "strings are king" approach since it simplifies the YAML model so much. However, having quoted objects get implicitly typed is too suprising. If the differentiation between quoted and plain scalars goes away, which I'd rather it did not, implicit typing should go with it. </unlurk> -tim |
From: Sean O'D. <se...@ce...> - 2004-09-10 17:27:01
|
On Friday 10 September 2004 10:00, Tim Hochberg wrote: > Sean O'Dell wrote: > > > >Definitely. Actually, I'd like them to be sent to loader the same way, > > both as scalars with just 32 as the value, since the quotes would be > > stripped away by the escape mechanism. They're then equal getting to the > > loader, which would implicitly type them both the same as !!int. > > Ugh. Please not this. I can see the appeal of the "strings are king" > approach since it simplifies the YAML model so much. However, having > quoted objects get implicitly typed is too suprising. If the > differentiation between quoted and plain scalars goes away, which I'd > rather it did not, implicit typing should go with it. The other way to go is to load both as the same style of scalar, and leave the quotes there and don't use quotes as a character escape mechanism nor consider it a particular style. Then the implicit typing phase can strip off the quotes and type the node as !!str. Either way, my original point was to get all implicit typing (and recognizing a scalar as a string IS implicit typing, no matter where it occurs) to happen in the same place, at one point, not partially during loading and then finished up later. Sean O'Dell |
From: Clark C. E. <cc...@cl...> - 2004-09-10 17:29:54
|
On Fri, Sep 10, 2004 at 10:00:56AM -0700, Tim Hochberg wrote: | >Definitely. Actually, I'd like them to be sent to loader the same way, | >both as scalars with just 32 as the value, since the quotes would be | >stripped away by the escape mechanism. They're then equal getting to | >the loader, which would implicitly type them both the same as !!int. | | Ugh. Please not this. I can see the appeal of the "strings are king" | approach since it simplifies the YAML model so much. However, having | quoted objects get implicitly typed is too suprising. If the | differentiation between quoted and plain scalars goes away, which I'd | rather it did not, implicit typing should go with it. Tim, I think that Sean was suggesting that your implicit typing, if you wanted such a thing, would be done at the application level. That said, we would probably report tags as ?str ?map and ?seq rather than as !!str !!map and !!seq so that people could explicitly request a tag. Clark -- Clark C. Evans Prometheus Research, LLC. http://www.prometheusresearch.com/ o office: +1.203.777.2550 ~/ , mobile: +1.203.444.0557 // (( Prometheus Research: Transforming Data Into Knowledge \\ , \/ - Research Exchange Database /\ - Survey & Assessment Technologies ` \ - Software Tools for Researchers ~ * |
From: Sean O'D. <se...@ce...> - 2004-09-11 02:54:35
|
On Friday 10 September 2004 10:26, Clark C. Evans wrote: > > I think that Sean was suggesting that your implicit typing, if you > wanted such a thing, would be done at the application level. That said, > we would probably report tags as ?str ?map and ?seq rather than as !!str > !!map and !!seq so that people could explicitly request a tag. No, I don't advocate putting it at the application level, just at a single point in the loader. Also, I don't think reporting scalars as strings is appropriate until they've actually undergone some typing to determine type. Scalars have no type until one is determined. Of course, that's just semantics; the value of the node will be the same, I just don't think it should be tagged as a string until it's gone through some typing. Sean O'Dell |
From: Clark C. E. <cc...@cl...> - 2004-09-11 03:22:50
|
On Fri, Sep 10, 2004 at 10:39:01AM -0700, Sean O'Dell wrote: | No, I don't advocate putting it at the application level, just at a | single point in the loader. That's a subtle position, perhaps too subtle. The problem with this distinction is that the loader interprets tags according to instructions from the application. So, while it may not be in the application, its done according to the application's direction. | Also, I don't think reporting scalars as | strings is appropriate until they've actually undergone some typing to | determine type. Scalars have no type until one is determined. Agreed. ?str didn't work for that reason, it implied string | Of course, that's just semantics; the value of the node will be the | same, I just don't think it should be tagged as a string until it's | gone through some typing. Care to comment on #4? - "quoting" # means escaping and only escaping - untagged # scalars are reported NULL not as a string - 23 # application-defined regex (perhaps done by loader) - ! 23 # private type, loaded into a string or cave drawing Cheers! Clark |
From: Clark C. E. <cc...@cl...> - 2004-09-10 21:43:06
|
On Fri, Sep 10, 2004 at 10:00:56AM -0700, Tim Hochberg wrote: | Ugh. Please not this. I can see the appeal of the "strings are king" | approach since it simplifies the YAML model so much. However, having | quoted objects get implicitly typed is too suprising. If the | differentiation between quoted and plain scalars goes away, which I'd | rather it did not, implicit typing should go with it. You gave me an idea, which I don't necessarly like; and which Brian has expressed disapproval, but alas, --- - 23 # tag:yaml.org,2002:str - "23" # tag:yaml.org,2002:str - [] # tag:yaml.org,2002:seq - {} # tag:yaml.org,2002:map - ! 23 # ?str - ! "23" # ?str - ! {} # ?map - ! [] # ?seq ... Thus, things are always concrete, unless turned on with ! flag. Best, Clark |