From: T. O. <tra...@ru...> - 2004-09-08 23:35:09
|
On Wednesday 08 September 2004 06:55 pm, Clark C. Evans wrote: > So, while I like your idea of !implicit-sequence, I'm not sure what > advantage it has over just plain !!seq, besides that Oren/T.Onoma > might agree to it and we can be done with this. Indeed you have a point with !!seq, because there is no variance possibel, as far as I can tell. BUT languages (and people) do sometimes distinguish between a Tuple and an Array or various ways to implement array (link list for example) so allowing the application to make a choice based on the fact that there was no explicit tag I think is a acceptable, as it can be useful. Obviously, it's useful scalar's all the time. I want to point out something here too. Remember what I said about - "x" is not different then - !!str That because the double quotes are just different way to write !!str. The same is true for the other tags. Imagine if we had some special quote-brackets for a seq. Say, --- %{ - 1 - 2 %} (Note this has nothing to do with [ ] They are shorthand for writting a sequence on one line, so they are not special in potentially semantic way.) So then using this special notation would be analogous to quotes on a scalar. Where saying !!seq for sure. Do you follow me here? Do you see what I'm getting at? All it is is a way for an app to treat these things specially, i.e. resolve them based on value, if the tag is not given. -- T. |
From: Sean O'D. <se...@ce...> - 2004-09-09 00:49:27
|
On Wednesday 08 September 2004 15:55, Clark C. Evans wrote: > > So, while I like your idea of !implicit-sequence, I'm not sure what > advantage it has over just plain !!seq, besides that Oren/T.Onoma > might agree to it and we can be done with this. Why do we need to mark nodes as implicitly tagged at all? I can see an application being interested in by what process a node was tagged, but couldn't the application just look at the tag type and what namespace/uri it belongs to? To me, a node marked implicit-seq tells me: a) it's a seq and b) the process it was tagged as a seq was the "default implicit typing process". Wouldn't it be more useful to simply allow the loader to tell an application by what process a node was tagged, such as reporting a namespace or something more specific like the schema uri? Sean O'Dell |
From: Damian C. <dam...@gm...> - 2004-09-08 21:42:20
|
On Wed, 8 Sep 2004 14:36:19 -0400, Clark C. Evans <cc...@cl...> wrote: > > However, your other examples where you hint at Python's problem with { > 1: 'integer', 1.0: 'float' } is an exceptional case, and it is > implementation specific. This is a situation where the Python mapping > and its native types fail to behave how the YAML Model specifies. Assuming that the YAML processor assigns different tags to them. If the implicitly interpolated tag for 1.0 and 1 is !!number (let's say) and they both had the same canonical form, then the YAML processor would recognize them as equal in the same way 1.0 = 1.00 and 0x2A = 052. Some programming languages' equivalent of a map compare using object-identity, others (such as Python) by value equality. I think that coming up with a form of words that lets YAML define 'uniqueness' for map keys that is completely bullet-proof in the face of these subtle differences between programming languages will not be possible. If we try to insist on one behaviour or another, we force implementers to abandon the native types in favour of YAML-specific equivalents, which would surely be inefficient and inconvenient. Maybe the cases that might cause conflicts (such as the 1 != 1.0 example) will have to be left deliberately ambiguous. Python dictionaries will silently overwrite one with the other; dot-Net's Hashtable will throw an exception if you Add a duplicate. And your processor might be configured to use completely different types anyway. On the other hand, cases where this causes divergent behaviour ought to be rare. For example, I am finding it difficult to imagine a real need to have separate mappings for numbers depending on whether I included a decimal point..! -- Damian |
From: Clark C. E. <cc...@cl...> - 2004-09-08 22:23:33
|
Hi Damian. On Wed, Sep 08, 2004 at 10:42:12PM +0100, Damian Cugley wrote: | > However, your other examples where you hint at Python's problem with { | > 1: 'integer', 1.0: 'float' } is an exceptional case, and it is | > implementation specific. This is a situation where the Python mapping | > and its native types fail to behave how the YAML Model specifies. | | Assuming that the YAML processor assigns different tags to them. Correct. | Some programming languages' equivalent of a map compare using | object-identity, others (such as Python) by value equality. I think | that coming up with a form of words that lets YAML define 'uniqueness' | for map keys that is completely bullet-proof in the face of these | subtle differences between programming languages will not be possible. Certainly. I was trying to address T.Onoma's requirement that his _valid_ YAML document be loaded into into some language XXX; he was insisting that if the mapping keys conflicted in this language, a structure that was no longer like a mapping would have to be used. I was pointing out, that a generic wrapper object is a better option. | If we try to insist on one behaviour or another, we force implementers | to abandon the native types in favour of YAML-specific equivalents, | which would surely be inefficient and inconvenient. I think in 99.9% of the cases, native objects will work just great, in the edge cases there are two clear options: - raise an exception and let the application cope, - wrap the offending item in a YAML wrapper. These are of course, not mutually exclusive. | Maybe the cases that might cause conflicts (such as the 1 != 1.0 | example) will have to be left deliberately ambiguous. Python | dictionaries will silently overwrite one with the other; dot-Net's | Hashtable will throw an exception if you Add a duplicate. And your | processor might be configured to use completely different types | anyway. No, we should have a clear specification and interpretation; its perfectly OK if not every native binding fits the model, that's why its called a "model". ;) | On the other hand, cases where this causes divergent behaviour ought | to be rare. For example, I am finding it difficult to imagine a real | need to have separate mappings for numbers depending on whether I | included a decimal point..! Exactly. Thanks, 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-08 21:56:03
|
On Tuesday 07 September 2004 12:58, Oren Ben-Kiki wrote: > > - Scalar nodes that have no explicit tag, and that are written in any > style except the "plain" style, are reported by the parser as if they > were associated with the tag "tag:yaml.org,2002:str". > > - All other nodes that have no explicit tag (both plain scalars and > untagged collection nodes) are reported by the parser as "having no > tag" (having a NULL tag). Why are there plain scalars at all? It seems like a scalar is a scalar until it passes through a typing process. I would think all tags would load as either !seq, !map or !scalar initially, and then when they passed through the built-in implicit transformation, they would become !!typed and any !scalar nodes that didn't get an implicit type there would be all become !!str. Sean O'Dell |
From: T. O. <tra...@ru...> - 2004-09-08 22:42:57
|
On Wednesday 08 September 2004 05:55 pm, Sean O'Dell wrote: > On Tuesday 07 September 2004 12:58, Oren Ben-Kiki wrote: > > - Scalar nodes that have no explicit tag, and that are written in any > > style except the "plain" style, are reported by the parser as if they > > were associated with the tag "tag:yaml.org,2002:str". > > > > - All other nodes that have no explicit tag (both plain scalars and > > untagged collection nodes) are reported by the parser as "having no > > tag" (having a NULL tag). > > Why are there plain scalars at all? <quote> But why is it so common? Mainly b/c YAML gives no core value to the common types it defines in it's type repository: !!int, !!bool, !!float, etc. These are the very types !!imp is transformed into _100%_ of the time. YAML's attempt at being a lowest common denominator might be too low --and that's really the source of the trouble with !!imp. </quote> > It seems like a scalar is a scalar until it passes through a typing > process. I would think all tags would load as either !seq, !map or !scalar > initially, and then when they passed through the built-in implicit > transformation, they would become !!typed and any !scalar nodes that didn't > get an implicit type there would be all become !!str. Well, if I put - "x" That doesn't need to go through any resolution. Understand by resolution we're talking about a very light weight transformation, such that all that happens is that the "variance" is taken out. But try as one might one is not going to separate that from actual transformation by the app --the same mechanisms will be used. So the distinction is required. -- T. |
From: Clark C. E. <cc...@cl...> - 2004-09-08 22:44:39
|
On Wed, Sep 08, 2004 at 02:55:46PM -0700, Sean O'Dell wrote: | Why are there plain scalars at all? Great question. Legacy perhaps. In the first pass of the system, all quoted scalars were given a default tag of !!str. And, depending upon the regular expression, we had a hard-specified list of other "common" data types that unquoted strings could be. However, we quickly got into an argument about those (regex,tag) pairs; and the concensus emerged: quoted and other non-plain scalars would have a default type of !!str, while the plain scalar would be a 'special case' and the application would determine its type, we called this implicit typing. I think that there is enough 'history' to indicate that people tend to write numbers and other non-string things without quotes, and use quotes when they really mean a string. Lots of languages take advantage of this mechanism to great effect. In short, if it doesn't make the model any harder, and if we can name a good syntax-only definition, then I'm happy to keep them. But, you are right to question the whole process, I'm starting to question if we need this complexity. Clark |
From: Sean O'D. <se...@ce...> - 2004-09-09 00:49:27
|
On Wednesday 08 September 2004 15:44, Clark C. Evans wrote: > On Wed, Sep 08, 2004 at 02:55:46PM -0700, Sean O'Dell wrote: > | Why are there plain scalars at all? > > would determine its type, we called this implicit typing. I think that > there is enough 'history' to indicate that people tend to write numbers > and other non-string things without quotes, and use quotes when they > really mean a string. Lots of languages take advantage of this > mechanism to great effect. It seems to me that quotes either serve one of two purposes: a) as an escape mechanism to allow characters in a value that the parser or loader might otherwise choke on b) as a flag that says "I am a string" I am all for uniformity, and it seems you could eliminate !!str as an implicit type until the point where all built-in implicits are transformed, leaving all scalars of type !scalar before that point. Basically, simplify the whole thing to this: - parser marks all nodes as !!seq, !!map or !!scalar - values wrapped in quotes are escaped and outer quotes are removed - implicit typing is performed, and all !!scalars become !!int, !!str, etc. The reason I mention this is because, at some point, I see schemas doing transformations, including replacing yaml.org for implicit typing and it could be a real bugaboo if a new default schema gets a freshly loaded graph filled with scalars, some of which are pre-tagged as !!str and some are not. It might be make life easier and things generally more consistent if we didn't have this stage of marking scalars as !!str before implicit typing is done. Sean O'Dell |
From: T. O. <tra...@ru...> - 2004-09-08 22:26:17
|
On Wednesday 08 September 2004 05:40 pm, Oren Ben-Kiki wrote: > We are going no where at all very fast until you and Onoma understand > that I absolutely, truly, really really mean it when I say that a node > with no tag, well, HAS NO TAG. Again: THE NULL TAG IS NOT A TAG. I ABSOLUTELY AGREE! But even so, you tell us what we should not do, but do not tell us what we should do. In the end the node must be SOMETHING. In the end the John Doe is a living human being. So what will it be in the end? what native type will they become? And what shall my application grad a hold of to determine it? My point is, that despite that it has NO TAG, its easier to work with if we give _the fact that it has no tag_ a name. Just like a hospital gives the unknown patient a name. That's why I suggested names that are completely outside of the !* syntax. But whatever you call it, I agree it is NOT !!map, !!seq, !!str. At any rate, it's not all that complex. Making them seemingly untouchable, a al NULL, would make for more complexity. -- T. |
From: Clark C. E. <cc...@cl...> - 2004-09-08 23:19:36
|
On Wed, Sep 08, 2004 at 06:26:08PM -0400, T. Onoma wrote: | My point is, that despite that it has NO TAG, its easier to work with if we | give _the fact that it has no tag_ a name. Just like a hospital gives the | unknown patient a name. | | That's why I suggested names that are completely outside of the !* syntax | But whatever you call it, I agree it is NOT !!map, !!seq, !!str. | At any rate, it's not all that complex. Making them seemingly | untouchable, a al NULL, would make for more complexity. If you are introducing a new syntax for this thingy, your solution isn't any better than Oren's. They both require their own API and a model for describing that API to help compliance. untagged mapping -> !personally-I-really-do-not-care untagged sequence -> !this-can-be-something-else-if-you-wish untagged plain scalar -> !as-long-as-they-are-different-from-each untagged other scalar -> !other-private-or-not-private-yhaoo That's all. Just make 'em syntax sugar and be done with it. All of this philosophical junk about names for having or not having names is just crap. In the end, the application gets to choose what it wishes to do with these tags. Clark |
From: T. O. <tra...@ru...> - 2004-09-08 23:47:39
|
On Wednesday 08 September 2004 07:19 pm, Clark C. Evans wrote: > On Wed, Sep 08, 2004 at 06:26:08PM -0400, T. Onoma wrote: > | My point is, that despite that it has NO TAG, its easier to work with if > | we give _the fact that it has no tag_ a name. Just like a hospital gives > | the unknown patient a name. > | > | That's why I suggested names that are completely outside of the !* syntax > | But whatever you call it, I agree it is NOT !!map, !!seq, !!str. > | > | At any rate, it's not all that complex. Making them seemingly > | untouchable, a al NULL, would make for more complexity. > > If you are introducing a new syntax for this thingy, your solution > isn't any better than Oren's. They both require their own API > and a model for describing that API to help compliance. > > untagged mapping -> !personally-I-really-do-not-care > untagged sequence -> !this-can-be-something-else-if-you-wish > untagged plain scalar -> !as-long-as-they-are-different-from-each > untagged other scalar -> !other-private-or-not-private-yhaoo > > That's all. Just make 'em syntax sugar and be done with it. All of > this philosophical junk about names for having or not having names is > just crap. In the end, the application gets to choose what it wishes > to do with these tags. Clark, that's exactly what I'm saying too! I was proposing a variant syntax just to "flag" (both computer and human) that something has to happen with these, you can't just let them go. They can't simply be passed through, b/c there is no native type to pass them through to. -- And its unwise to make generic real types to catch them if they do b/c you fall into the trap of treating them as real types. (I think Oren would agree with me there.) All you really need to do is make them an actual !!str (or whatever) but with a flag that says "plain", that's fine, but it has to be resolved to a real type, like !!str. Also, again, there is no such thing as "untagged other scalar". "x" == !!str x -- T. |
From: T. O. <tra...@ru...> - 2004-09-08 23:19:41
|
On Wednesday 08 September 2004 06:23 pm, Clark C. Evans wrote: > Certainly. I was trying to address T.Onoma's requirement that his > _valid_ YAML document be loaded into into some language XXX; he was > insisting that if the mapping keys conflicted in this language, a > structure that was no longer like a mapping would have to be used. =A0I > was pointing out, that a generic wrapper object is a better option. Well, that's what I'm trying to point out. If a "customer" loaded this: ---=20 a: 1 b: 2 a: 3 What would happen? According to the "YAML Model" an error would be be throw= n=20 saying "you got it wrong dumb dumb". (Okay, it'll use some tech jargon, but= =20 that's the jist of the message.) But the computer should not be so=20 presumptuous! It should at least attempt to assume that what the "customer"= =20 gave it is what the "customer" wants. Impossible you say. That doesn't fit the "model"! And the customer responds= ,=20 "you mean what I am trying to do is not allowed?" And you say, "Nope. It is= =20 invalid. But you can do this, that and the other thing to emulate ... with = a=20 type transformat..." At this point customer starts looking around for anoth= er=20 tool. (And don't tell me this is out side the scope of serialization. The=20 fact Ruby and Python have an incompatibility b/c of it proves that it is=20 not.) I know, I know. You're looking at the example and screaming "THAT'S NOT THE= =20 YAML MODEL!" And that's what I'm telling you. That is the problem. Your ide= a=20 of the YAML model has a chink in its armor: while it's supposed to be=20 semantic-less, the fact that the above would error is proof that it isn't.= =20 And hence you get these warty problems we're now discussing. I'm asking you to rethink a little --just a little. Like you said 99.9% of = the=20 time nothing like this will even come up. So why not just gracefully allow = it=20 when it does? Then all those ugly warts go away. And you might actually=20 discover it is occasionly useful too. By the way, if I meant a !!map without question I would put --- !!map a: 1 b: 2 a: 3 And an error would be quite right. Anyhow, that' my suggestion concerning this. It makes things a lot less=20 complex, gets rid of the warts, and is a very simple thing to offer. I=20 already outlined the two simple points that would be required in a previous= =20 post. =2D-=20 T. |
From: Clark C. E. <cc...@cl...> - 2004-09-08 23:37:27
|
On Wed, Sep 08, 2004 at 07:19:35PM -0400, T. Onoma wrote: | If a "customer" loaded this: | | --- | a: 1 | b: 2 | a: 3 | | What would happen? According to the "YAML Model" an error would be | be thrown saying "you got it wrong dumb dumb". Yep. I'd expect every YAML Parser to do the same thing, in fact, this exact item will have to be in the YAML Test Suite. | Anyhow, that' my suggestion concerning this. It makes things a lot less | complex, gets rid of the warts, and is a very simple thing to offer. I'm not even going to humor a reconsideration of the core model, sorry. Clark |
From: David H. <dav...@bl...> - 2004-09-09 01:54:21
|
T. Onoma wrote: > On Wednesday 08 September 2004 06:23 pm, Clark C. Evans wrote: > >>Certainly. I was trying to address T.Onoma's requirement that his >>_valid_ YAML document be loaded into into some language XXX; he was >>insisting that if the mapping keys conflicted in this language, a >>structure that was no longer like a mapping would have to be used. I >>was pointing out, that a generic wrapper object is a better option. > > Well, that's what I'm trying to point out. If a "customer" loaded this: > > --- > a: 1 > b: 2 > a: 3 > > What would happen? According to the "YAML Model" an error would be be thrown > saying "you got it wrong dumb dumb". (Okay, it'll use some tech jargon, but > that's the jist of the message.) But the computer should not be so > presumptuous! It should at least attempt to assume that what the "customer" > gave it is what the "customer" wants. > > Impossible you say. That doesn't fit the "model"! And the customer responds, > "you mean what I am trying to do is not allowed?" And you say, "Nope. It is > invalid. But you can do this, that and the other thing to emulate ... with a > type transformat..." No need for any type transformations: --- - a: 1 - b: 2 - a: 3 And yes, people defining YAML-based formats do need to understand and follow the YAML model. Most end-users do not; in practice they just follow the examples. -- David Hopwood <dav...@bl...> |
From: T. O. <tra...@ru...> - 2004-09-09 00:09:25
|
On Wednesday 08 September 2004 07:37 pm, Clark C. Evans wrote: > On Wed, Sep 08, 2004 at 07:19:35PM -0400, T. Onoma wrote: > | If a "customer" loaded this: > | > | --- > | a: 1 > | b: 2 > | a: 3 > | > | What would happen? According to the "YAML Model" an error would be > | be thrown saying "you got it wrong dumb dumb". > > Yep. I'd expect every YAML Parser to do the same thing, in > fact, this exact item will have to be in the YAML Test Suite. > > | Anyhow, that' my suggestion concerning this. It makes things a lot less > | complex, gets rid of the warts, and is a very simple thing to offer. > > I'm not even going to humor a reconsideration of the > core model, sorry. You act like I'm putting a match to the whole model! This is really a very minor point, one new _recommended_ type and a small three sentence foot note to the spec. Yet, you act like the whole thing would tumble apart if it were allowed. Unfortunately, you will have to continue to deal with the ambiguities created when "resolution" fails due to TAG, or float vs. integer, or implicit tags, etc. You will endlessly debate the question of equality, needlessly, and you will continue to wonder "who John Doe really is". Mark my words: You will _never_ have 100% implementation compliance to the spec. I think great things about you, but you're just too caught up on a theory despite practicality. By the way, have you ever heard the saying "Sometimes you have to kill your babies?" Well, IMHO, you have yourself a baby. Yes, we've debated this before. -- T. |
From: David H. <dav...@bl...> - 2004-09-09 02:07:00
|
T. Onoma wrote: > On Wednesday 08 September 2004 07:37 pm, Clark C. Evans wrote: > >>On Wed, Sep 08, 2004 at 07:19:35PM -0400, T. Onoma wrote: >>| If a "customer" loaded this: >>| >>| --- >>| a: 1 >>| b: 2 >>| a: 3 >>| >>| What would happen? According to the "YAML Model" an error would be >>| be thrown saying "you got it wrong dumb dumb". >> >>Yep. I'd expect every YAML Parser to do the same thing, in >>fact, this exact item will have to be in the YAML Test Suite. >> >>| Anyhow, that' my suggestion concerning this. It makes things a lot less >>| complex, gets rid of the warts, and is a very simple thing to offer. >> >>I'm not even going to humor a reconsideration of the >>core model, sorry. > > You act like I'm putting a match to the whole model! This is really a very > minor point, one new _recommended_ type and a small three sentence foot note > to the spec. Yet, you act like the whole thing would tumble apart if it were > allowed. I agree with Clark here. The YAML data model is both theoretically elegant and maps really well to practical programming languages. For any other data model, it would also be possible to come up with examples that require a little indirection in order to make the example fit. > Unfortunately, you will have to continue to deal with the ambiguities created > when "resolution" fails due to TAG, or float vs. integer, or implicit tags, > etc. You will endlessly debate the question of equality, needlessly, and you > will continue to wonder "who John Doe really is". There are similarly tricky issues whatever types are used as the basis: using different types just moves the trickiness around -- for example from equality to function application or to testing whether a relation is a function (I've spent a long time thinking about this). -- David Hopwood <dav...@bl...> |
From: Clark C. E. <cc...@cl...> - 2004-09-09 00:24:07
|
On Wed, Sep 08, 2004 at 03:32:53PM -0400, T. Onoma wrote: | "This is a situation where the Python mapping and its native types | fail to behave how the YAML Model specifies. For these sorts of | icky cases where the native binding doesn't match YAML's _semantics_ | ..." [my emphasis] | | So YAML is doing exactly what it's supposed to keep it's nose out of. YAML has 3 models - Presentation, Serialization, and Representation. These models are there to help implementations, make as YAML interoperable as possible with various environments, and to provide a language to describe generic processes, such as a Schema language. Without a formal model these things are all very difficult, and the only fallback is 'the semantics is the code'. When you do this, you assume one code base, one implementation. | Force that semantic value and you're forced to tame an unruly | transformation --that's too bad, since there is quite a natural --even | proper, one. The YAML model specifies what _information_ the YAML Processor should deliver to the Application. It does not force any semantics on the Application, in particular, it can transform to its hearts content. | No, !bingles is very real. In the last draft proposal I fixed this. There is no way to explictly type a ?scalar in the YAML syntax, for example !?scalar is actually '!?scalar' != '?scalar'. So, we avoid that whole bag of worms. | To be very clear, it really just boils down to this: | | - Add !!rel to the repository Provide me a thought-out specification for it, and I'll probably add it. We will not deny a thoughtful tag ;) | - Add a statement along these lines: "If the _recommended_ type | !!rel has been implemented, and upon resolution to native-type, | a '!variant-map' does not meet the requirements of yaml's !!map | (namely the inequality of keys), and also assuming no other | transformation has been specified explicitly for this tag, | then the _recommended_ behavior is to transform it into a !!rel. | If !!rel is not implemented then the recommended behavior is, by | necessity, to throw an error." You can post this as a separate 'recommendation' you have for post-YAML processors. If its a good idea, your module will catch fire and everyone will use it. Cheers! Clark |
From: T. O. <tra...@ru...> - 2004-09-09 02:06:55
|
On Wednesday 08 September 2004 08:24 pm, you wrote: > Provide me a thought-out specification for it, and I'll > probably add it. We will not deny a thoughtful tag ;) Full Name: Relations URI: tag:yaml.org,2002:rel Shorthand: !!rel Kind: Mapping. Definition: An unordered set of key:value pairs. A simple type similar to a mapping but without the restriction on duplicate "keys", sometimes called a 'dmap'. This type is usable as a fault-catch for when an implicit mapping fails inequality validation on its key values. Currently, the closest approximation YAML can provide to this type is a notation for representing this as a null-value mapping with two-element sequence keys. Most programming languages do not have a built-in native data type for supporting relations (an exception being Prolog). Such data types are usually provided by libraries. If no such data type is available, an application may resort to loading !!rel into a sequence of two-element sequences, and disregarding all order information. This is recommended becuase some languages cannot handle a mapping with sequences for keys. The !!rel tag may be given explicitly, or the application may choose to implicitly type invalid mappings to !!rel, rather then throw an error. Example 1. # Explicitly typed relation from null-value map of two element sequences. tasks: !!rel ? [ meeting, with team ] ? [ meeting, with boss ] ? [ break, lunch ] ? [ meeting, with client ] Example 2. # Explicitly typed relation from sequence of two-element sequences. tasks: !!rel - [ meeting, with team ] - [ meeting, with boss ] - [ break, lunch ] - [ meeting, with client ] Example 3. # An implicit relations due to unresolvable mapping, # as would occur for this example in Python. numbers: 1 : one 1.0 : one point zero > You can post this as a separate 'recommendation' you have for > post-YAML processors. If its a good idea, your module will > catch fire and everyone will use it. Ha ha. But hey, at least there it is! -- T. |
From: T. O. <tra...@ru...> - 2004-09-09 02:26:59
|
On Wednesday 08 September 2004 09:54 pm, David Hopwood wrote: > No need for any type transformations: > > --- > - a: 1 > - b: 2 > - a: 3 Incorrect. The most correct explicit form would be: --- !!rel ? [ a, 1 ] ? [ b, 2 ] ? [ a, 3 ] Alas, some languages do not support sequences for mapping keys, thus if !!rel is not supported the above will fail. In which case, --- !!rel - [ a, 1 ] - [ b, 2 ] - [ a, 3 ] is the closet sure thing, but is not exactly correct in that it implies order although there is none. Relations is a kind of mapping, not a sequence...well sort of. It can have duplicate keys. (See the problem?) A general use for !!rel is to catch invalid implicit mappings due to key duplication. So yes, my first example is technically correct. For example: --- 1 : one 1.0 : on point zero Looks good for YAML Model, but bombs in Python. Python should have the option (remember who is in control) to transform to !!rel. And if you can do _that_. then there's no reason not to allow the other, more obvious example. > And yes, people defining YAML-based formats do need to understand and > follow the YAML model. Most end-users do not; in practice they just follow > the examples. Sure, but that's not my point. My point is that the "YAML Model" (which is a dynamic thing BTW) has an contradiction in it. We can work around contradictions, but it doesn't mean they aren't there. -- T. |
From: David H. <dav...@bl...> - 2004-09-09 02:48:49
|
T. Onoma wrote: > On Wednesday 08 September 2004 09:54 pm, David Hopwood wrote: > >>No need for any type transformations: >> >> --- >> - a: 1 >> - b: 2 >> - a: 3 > > Incorrect. The most correct explicit form would be: > > --- !!rel > ? [ a, 1 ] > ? [ b, 2 ] > ? [ a, 3 ] That's slightly better, yes, but the form I gave will work fine as well. Remember, a YAML-based format can always use an ordered type but stipulate that the ordering is not important. > Alas, some languages do not support sequences for mapping keys, thus if !!rel > is not supported the above will fail. In which case, > > --- !!rel > - [ a, 1 ] > - [ b, 2 ] > - [ a, 3 ] > is the cloest sure thing, but is not exactly correct in that it implies order > although there is none. If a language doesn't natively support a particular structure, then the fallback to another structure should be done by the API, not in YAML documents. Otherwise, documents will be full of workarounds. > Relations is a kind of mapping, not a sequence...well > sort of. It can have duplicate keys. (See the problem?) A relation is *not* a kind of mapping. A mapping is a kind of relation. YAML does not use relations as a basic type. That would be a different data model. The "set of sequences" approach is a perfectly reasonable way of representing relations, which generalizes nicely to n-ary relations. (It doesn't generalize quite as well to multirelations, but more on that separately.) > A general use for !!rel is to catch invalid implicit mappings due to key > duplication. So yes, my first example is technically correct. For example: > > --- > 1 : one > 1.0 : on point zero > > Looks good for YAML Model, but bombs in Python. Python should have the option > (remember who is in control) to transform to !!rel. And if you can do _that_. > then there's no reason not to allow the other, more obvious example. Note that 1 and 1.0 are distinct values in Python; it is possible to distinguish them using the 'is' operator, even though 1 = 1.0. So a dictionary type provided by a YAML API could distinguish 1 and 1.0 as keys, and that dictionary could present the same interface as any other dictionary. >>And yes, people defining YAML-based formats do need to understand and >>follow the YAML model. Most end-users do not; in practice they just follow >>the examples. > > Sure, but that's not my point. My point is that the "YAML Model" (which is a > dynamic thing BTW) has an contradiction in it. No, it doesn't. Especially not if the treatment of equality described in my proposals #2/#3 is adopted. -- David Hopwood <dav...@bl...> |
From: Clark C. E. <cc...@cl...> - 2004-09-09 03:33:30
|
On Wed, Sep 08, 2004 at 10:26:53PM -0400, T. Onoma wrote: | --- !!rel | ? [ a, 1 ] | ? [ b, 2 ] | ? [ a, 3 ] ? [ a, 3 ] Would make the !!rel invalid (duplicate key), is this what you intend? If not, the second notation, | --- !!rel | - [ a, 1 ] | - [ b, 2 ] | - [ a, 3 ] is probably the second best, or as David suggested, using !!omap but not considering the order important. |
From: T. O. <tra...@ru...> - 2004-09-09 04:28:25
|
On Wednesday 08 September 2004 11:33 pm, Clark C. Evans wrote: > On Wed, Sep 08, 2004 at 10:26:53PM -0400, T. Onoma wrote: > | --- !!rel > | ? [ a, 1 ] > | ? [ b, 2 ] > | ? [ a, 3 ] > ? [ a, 3 ] > > Would make the !!rel invalid (duplicate key), is > this what you intend? If not, the second notation, No. That would be invalid (or the duplicate ignored). Did I typo that? Or are you just asking? > | --- !!rel > | - [ a, 1 ] > | - [ b, 2 ] > | - [ a, 3 ] > > is probably the second best, or as David suggested, > using !!omap but not considering the order important. Understandably that is one way to emulate, albeit that order is implied is what's iky about it. It's the very argument that was used _for_ !!omap, as I recall. -- T. |
From: T. O. <tra...@ru...> - 2004-09-09 02:35:44
|
On Wednesday 08 September 2004 10:06 pm, David Hopwood wrote: > I agree with Clark here. The YAML data model is both theoretically elegant > and maps really well to practical programming languages. For any other data > model, it would also be possible to come up with examples that require a > little indirection in order to make the example fit. But I'm specifically pointing out where it is NOT elegant, where it does'nt map well. And your last statement it not true. Mathematics has completely "modelled" _all_ "kinds". Relations, btw is one of them. A mapping, btw again, is a kind of relations. > There are similarly tricky issues whatever types are used as the basis: > using different types just moves the trickiness around -- for example from > equality to function application or to testing whether a relation is a > function (I've spent a long time thinking about this). But you don't need to think about it! YAML should be 100% type-less, 100% semantic-less! Only the formal structure matters. Semantics belongs to the application. Tags are only tags, they are not types, they are hints for type. YAML itself need know nothing what they mean at all --or how they are "equal". -- T. |
From: David H. <dav...@bl...> - 2004-09-09 02:57:28
|
T. Onoma wrote: > On Wednesday 08 September 2004 10:06 pm, David Hopwood wrote: > >>I agree with Clark here. The YAML data model is both theoretically elegant >>and maps really well to practical programming languages. For any other data >>model, it would also be possible to come up with examples that require a >>little indirection in order to make the example fit. > > But I'm specifically pointing out where it is NOT elegant, where it does'nt > map well. And your last statement it not true. Mathematics has completely > "modelled" _all_ "kinds". Relations, btw is one of them. A mapping, btw > again, is a kind of relations. Yes, the usual way to model a relation in mathematics is as a set of pairs -- which is exactly how you've suggested to model it in YAML, and that works fine. I don't see the problem. >>There are similarly tricky issues whatever types are used as the basis: >>using different types just moves the trickiness around -- for example from >>equality to function application or to testing whether a relation is a >>function (I've spent a long time thinking about this). > > But you don't need to think about it! YAML should be 100% type-less, 100% > semantic-less! Only the formal structure matters. Semantics belongs to the > application. Tags are only tags, they are not types, they are hints for type. > YAML itself need know nothing what they mean at all --or how they are > "equal". It is simply incorrect to say that equality does not need to be defined. Mathematical sets, functions, relations, multisets, multirelations, sequences, graphs, etc. all use equality in their definitions. -- David Hopwood <dav...@bl...> |
From: T. O. <tra...@ru...> - 2004-09-09 03:26:00
|
On Wednesday 08 September 2004 10:57 pm, David Hopwood wrote: > It is simply incorrect to say that equality does not need to be defined. > Mathematical sets, functions, relations, multisets, multirelations, > sequences, graphs, etc. all use equality in their definitions. That's not what I'm saying. I'm saying thats equality is an issue of the application's, ONLY. -- T. |