Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

## Re: [Yaml-core] on type families and formalism

 Re: [Yaml-core] on type families and formalism From: Brian Ingerson - 2001-11-27 18:45:16 ```On 27/11/01 20:10 +0200, Oren Ben-Kiki wrote: > Deeper issues: > The formal definitions look too cumbersome. As one with a math degree I can > see where it comes from and I understand the motivation to include them, but > we should find a way to make it less intimidating to the non-mathematicians. > People have a good intuition of what "identity", "equality", "mapping" etc. > mean and we should build on that somehow... I admit it is a pretty > problem... I had an idea. (Similar to Oren's suggestion) For each point int the info model section, provide the following in order: - A concise formal one sentence description - An explanation in humanese (perhaps I can help, I'm a human ;) - Some easy to understand examples. Cheers, Brian ```

 RE: [Yaml-core] on type families and formalism From: Oren Ben-Kiki - 2001-11-27 07:41:03 ```Clark, I've just printed Clark-15 and will go over it. My gut feeling is that: - We need to define what a transfer method transfers *to*. I fully agree this doesn't need to be a formal definition - call it a "description of the result of applying the transfer method" rather than "definition of a type family" if this is clearer. But I can't see how you can drop the concept itself and still define a transfer method in a meanuingful way. - As for using a formalism, my experience is that the formal mathematical definition of most things is extremely short, if obscure (typically one sentence). You can give that and follow by an informal, readable text which doesn't have to cover all the ugly cases (the single math sentence did that for you). As an example: Formal speak: "collections are equal if there is a 1-1 onto mapping between them such that the mapped pairs are equal". Human speak: ... longer, informal description... - I think we should go lightly on the "formal speak". A sentence here and there should be enough. This seems to be what you are aiming at, if I read your E-mail right. Carry on the good work! Have fun, Oren Ben-Kiki ```
 RE: [Yaml-core] on type families and formalism From: Oren Ben-Kiki - 2001-11-27 18:10:04 ```OK, I just did a quick pass through Clark-15. BTW its title says Clark-10 :-) Minor wording issues: Section 3.1: 2nd paragraph: ', binary values' => 'and binary values'. Section 3.2: ', scalar' => 'and scalar'. I also think it would be a good idea to link the mentioned terms with tjeir definition. Section 3.2.2: move 'regex' to be last, and add wording so it is clear it applies to the scalar node styles (hence only makes sense if the transfer method is capable of handling a scalar in the first place). Section 3.2.3: make the anchor cover 'later section' instead of just 'section'. Section 3.3.1: 'quoted' => 'escaped'; 'All but the block' => 'All but the escaped'. Section 5.1: Wording has to be changed to refer to type families rather than native types etc. For example we have three core type families, not three core native types. Section 5.3.*: Say "none" for transfer methods without a regexp. And move the type family to be before the regexp to reflect the same order as in the definition of node properties. Section 5.3.2: Say that escaping for "qouted" is exactly the same as for escaped scalars. Section 5.3.6: The example says !ref. Section 5.3.9: We should quote the first 3 keys in the example instead of folding them. Section 5.4: 'the explicit !str' => 'an explicit str'. Deeper wording issues: Section 3.2.4: defining identity as a relationship seems strange to me. It seems clearer to do it as a node property. Also, section 3.2.4 talks about "object identity" - it should talk about "node identity". Section 3.2.7: I think the definition of scalar equality is buggy. For example is '12.0' different from '12.' ? You may want to change the wording of the "string representation" to "canonical string representation" to be on the safe side here. Section 3.3.2: This is *wrong*. The comment is not attached to a *node*, it is always attached to a *collection entry* (a key:value *pair* - since we are considering sequence entries to be key:value pairs as well). Perhaps representing a collection as a set of pairs makes more sense after all? Section 3.3.3: I thought we called these directives? This seems clearer to me than declarations. Why the change? Section 3.4: Be sure to mention the key order issue. Section 4.3.4: You removed my non_word_tail production (either that or didn't sync with my latest). I want my "!java.package.class[]" and my "!.Perl::Package". *Please* give them back to me! Section 5.3: I see no point in assigning a specific scalar style to transfer methods. They always apply to all of them, and if there's a regexp they also work for implicit scalars; no special notation is necessary (but proper wording for the regexp property is required). Thus it is enough to say "map, seq, implicit/explicit scalar", not "block, flow". For example explicit base64 can be applied to blocks or escaped or plain... not only to folded. Likewise one can write --- null: !null || ~ --- So null is not limited to a plain scalar either. Deeper issues: The formal definitions look too cumbersome. As one with a math degree I can see where it comes from and I understand the motivation to include them, but we should find a way to make it less intimidating to the non-mathematicians. People have a good intuition of what "identity", "equality", "mapping" etc. mean and we should build on that somehow... I admit it is a pretty problem... Summary: - Lots of small and not quite small wording issues; - I want back my non_word_tail!!! - We need to find a way to handle the formalisms. - I like the type families as they are presented today. Have fun, Oren Ben-Kiki ```
 Re: [Yaml-core] on type families and formalism From: Brian Ingerson - 2001-11-27 18:45:16 ```On 27/11/01 20:10 +0200, Oren Ben-Kiki wrote: > Deeper issues: > The formal definitions look too cumbersome. As one with a math degree I can > see where it comes from and I understand the motivation to include them, but > we should find a way to make it less intimidating to the non-mathematicians. > People have a good intuition of what "identity", "equality", "mapping" etc. > mean and we should build on that somehow... I admit it is a pretty > problem... I had an idea. (Similar to Oren's suggestion) For each point int the info model section, provide the following in order: - A concise formal one sentence description - An explanation in humanese (perhaps I can help, I'm a human ;) - Some easy to understand examples. Cheers, Brian ```
 Re: [Yaml-core] on type families and formalism From: Clark C . Evans - 2001-11-27 22:15:00 ```On Tue, Nov 27, 2001 at 10:45:12AM -0800, Brian Ingerson wrote: | - A concise formal one sentence description | - An explanation in humanese (perhaps I can help, I'm a human ;) I think I've found a good balance with the current spec... file:///C:/cygwin/home/cce/cce-16.html#concept-model could you provide additional feedback? | - Some easy to understand examples. I started to do this, but it ended up duplicating alot of the later sections or the preview. Hopefully the existing wording can escape us from this. Best, Clark ```
 Re: [Yaml-core] on type families and formalism From: Clark C . Evans - 2001-11-27 22:13:18 ```| Section 3.2.2: move 'regex' to be last, and add wording so it is clear it | applies to the scalar node styles (hence only makes sense if the transfer | method is capable of handling a scalar in the first place). Please suggest wording. | Section 5.3.2: Say that escaping for "qouted" is exactly the same as for | escaped scalars. Please suggest wording. | Section 3.2.4: defining identity as a relationship seems strange to | me. It seems clearer to do it as a node property. I've updated the wording see if this is better. We only require two equivalence relations... (equality and identity) we don't require a unique node identifier and we don't want to define integer equality on those node identifiers, IMHO this would be more difficult. Besides, asking for a unique node identifier is stronger requirement. | Section 3.2.7: I think the definition of scalar equality is buggy. | For example is '12.0' different from '12.' ? We need equality to have a nice definition (at the information model level) without depending on transfer method interpretation. | You may want to change the wording of the "string representation" | to "canonical string representation" to be on the safe side here. Ahh. Ok. Where each transfer method defines the canonical form for a given string. Ok. Let me think about how to do this. | Section 3.3.2: This is *wrong*. The comment is not attached to | a *node*, it is always attached to a | *collection entry* It works if you use alias nodes. I'd rather stay away from defining node paris, but we can do it if required. Certainly the common set theory definition of a function is a set of pairs... I was just hoping to avoid this. We will need node-set later on, so I didn't mind defining this (besides, most languages have a keys() method for obtaining the domain node set) To work around this (and other issues that popped up), I was thinking about merging the serialization model with the syntax enhancements. Not sure if I like this approach, but it solves the problem via alias nodes. | Section 4.3.4: You removed my non_word_tail production (either that or | didn't sync with my latest). I want my "!java.package.class[]" and my | "!.Perl::Package". *Please* give them back to me! I did? I thought I removed the non_word_tail production on the "org.yaml.map" and "org.yaml.seq" items only as we had discussed. | Section 5.3: I see no point in assigning a specific scalar style to | transfer methods. They always apply to all of them... Ok. Can you suggest specific replacements? | The formal definitions look too cumbersome. As one with a math degree I can | see where it comes from and I understand the motivation to include them, but | we should find a way to make it less intimidating to the non-mathematicians. | People have a good intuition of what "identity", "equality", "mapping" etc. | mean and we should build on that somehow... Please see my recent pass. Hopefully this is a bit more clear. For the definition of disjoint I found it hard to avoid a more formal style. | - Lots of small and not quite small wording issues; I fixed the ones you enumerated. There are still many more. | - I want back my non_word_tail!!! I have no problem allowing this in the general case, just not with org.yaml.map and org.yaml.seq | - We need to find a way to handle the formalisms. I think I fixed this. At least, it is much more readable to my girlfriend now (an art history person) | - I like the type families as they are presented today. Good deal. Best, Clark ```