From: Oren Ben-K. <or...@ri...> - 2001-08-09 12:13:21
|
Clark C . Evans [mailto:cc...@cl...] wrote: > | - The lexer will expand a shorthand map form... > This is _not_ simple. Like I said, "Simple" suffers. I'd rather sacrifice "Simple" than "Native" and "RoundTrip". Your priorities are different. OK. > It's not obvious. I'd just rather throw an error > if the user can't support an integer. It's not like > the above data structure is even going to be remotely > useable to the application programmer anyway. Strong disagreement. It is very usable for a large class of applications - generic, schema independent applications: Y-Grep, Y-Digital-Sign.,Y-Pretty-Print, Y-Word-Count, Y-Transform, Y-Editor, Y-Diff, Y-Merge, Y-Browse... I *want* these to be possible. > And... if it is, then they can provide a "type handler" > which does exactly this. Breakthrough! We have narrowed the difference between us to: Me: The YAML system *must* expand unrecognized !class as shorthand maps (likewise for '&', '*', '~' if it doesn't support them). You: The YAML system *may* do exactly the same, but may also just emit a warning and strip away the data. I agree! Anyone who is knowingly throwing away data when there's an alternative is within his rights. As long as he doesn't call it round trip :-) So, the proposed compromise: - The YAML data model would be a graph of nodes, each node is a null or a map, list, reference, or scalar, each non-null node having a type. - This model may be serialized to text: node: !type &anchor <map/list/string> - This model may be flattened into a pure map/list/string model: node: % !: class &: anchor =: <map/list/string> This is just an alternative representation of the same typed-node model, not a lower layered model. Just like the serialized form is an alternative form of the model. There are probably a zillion other ways to represent the same model (e.g., using RDF). This one is only special in that it is the "by convention" way to represent the full model through REXX/Shell/etc. pure map/list/string data structures. - Unquoted scalar types are subject to regexp based type inference (OK, no leading alpha). Using single quotes prevents this inference. The set of ~ for null, *<anchor> for reference, integers and floats is the "by convention" set for exchanging data between modern programming languages. - An application loading the file may choose to use whatever works for it. It "should" try to recognize as many types as possible. It is its choice whether to discard or flatten unrecognized type data (Y-Diff will flatten, Y-Load-Http-Config will complain and discard). Agreed? Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2001-08-09 12:41:26
|
On 09/08/01 15:14 +0200, Oren Ben-Kiki wrote: > node: !type &anchor <map/list/string> > > - This model may be flattened into a pure > map/list/string model: > > node: % > !: class > &: anchor > =: <map/list/string> Makes sense to me. > Agreed? FWIW, I Agree. In fact, I agree with almost all of what Oren has been saying, and also most of what Clark has been saying. Sometimes I even agree with both of you, when you disagree. Sometimes that's because I both think you're saying the same thing, and sometimes it's because I just don't care :) Anyway, I can leave the shorthand out for my implementation. Although I might put it in just for fun. Time out for fun. Remember that good old Devo song? o/~ So your feeling under the gun, circumstances got you on the run... o/~ > > Have fun, Oh, don't worry about that my friend. |
From: Clark C . E. <cc...@cl...> - 2001-08-09 20:27:52
|
On Thu, Aug 09, 2001 at 05:41:20AM -0700, Brian Ingerson wrote: | FWIW, I Agree. | | In fact, I agree with almost all of what Oren has been saying, and also most | of what Clark has been saying. Sometimes I even agree with both of you, when | you disagree. Sometimes that's because I both think you're saying the same | thing, and sometimes it's because I just don't care :) +1 Best, Clark |
From: Clark C . E. <cc...@cl...> - 2001-08-09 20:13:59
|
On Thu, Aug 09, 2001 at 03:14:10PM +0200, Oren Ben-Kiki wrote: | > It's not obvious. I'd just rather throw an error | > if the user can't support an integer. It's not like | > the above data structure is even going to be remotely | > useable to the application programmer anyway. | | Strong disagreement. It is very usable for a large | class of applications - generic, schema independent | applications: Y-Grep, Y-Digital-Sign.,Y-Pretty-Print, | Y-Word-Count, Y-Transform, Y-Editor, Y-Diff, Y-Merge, | Y-Browse... I *want* these to be possible. Right, and I'm with you here. Chances are these items will be written without trying to convert the YAML into a native data structure... but they will also be done with full knowledge of the YAML information model. Perhaps using the sequential access interface. And in this case, the sequential access interface will have a type attribute on each node; so no rewrite is required. It is not necessary that the sequential interface knows the details of the given class/type if all it is doing is moving the node around... this even applies to a unknown typed node... there just isn't a problem here. It's the native access that is the problem. I'd like the warnings to occur when one tries to "cast" a YAML stream into native data structures, but one or more types is not found. In this case, one won't be doing generic processing. | Me: The YAML system *must* expand unrecognized !class as | shorthand maps (likewise for '&', '*', '~' if it doesn't | support them). | | You: The YAML system *may* do exactly the same, but may | also just emit a warning and strip away the data. Or, if using an interface which supports the color on each node... it may just emit a warning and not strip away the type information. This is the generic YATL application. | I agree! Anyone who is knowingly throwing away data when | there's an alternative is within his rights. As long as | he doesn't call it round trip :-) Right. Or, they may do the round-trip at the application level, where the appliction programer preserves the data structures. For instance, let's assume the tuple type: (2,3): hello (3,4): baby In this case, the perl programmer may say, "well, for purposes of my work, I can treat the keys as strings with no loss of generality" | So, the proposed compromise: | | - The YAML data model would be a graph of nodes, | each node is a null or a map, list, reference, or scalar, | each non-null node having a type. | | - This model may be serialized to text: | | node: !type &anchor <map/list/string> | | - This model may be flattened into a pure | map/list/string model: | | node: % | !: class | &: anchor | =: <map/list/string> | | This is just an alternative representation of the | same typed-node model, not a lower layered model. | Just like the serialized form is an alternative | form of the model. There are probably a zillion | other ways to represent the same model (e.g., | using RDF). This one is only special in that | it is the "by convention" way to represent | the full model through REXX/Shell/etc. | pure map/list/string data structures. | | - Unquoted scalar types are subject to regexp | based type inference (OK, no leading alpha). | Using single quotes prevents this inference. | The set of ~ for null, *<anchor> for reference, | integers and floats is the "by convention" | set for exchanging data between modern | programming languages. | | - An application loading the file may choose | to use whatever works for it. It "should" | try to recognize as many types as possible. | It is its choice whether to discard or flatten | unrecognized type data (Y-Diff will flatten, | Y-Load-Http-Config will complain and discard). | | Agreed? YES. This is a very good compromise. Best, Clark |