Re: Equality

Hi all,

To discuss the equality, we have to distinguish 1 == 1.0 from 
a_map[1] == a_map[1.0] . In many languages, the former is true 
because 1 is implicitly converted to 1.0 before conversion and 
then compared to 1.0. In contrast, the latter is almost always 
false because 1 and 1.0 are unequal objects by themselves. 
JavaScript is an exceptional language.

But, since the exception is not negligible, I agree with giving
up specifying YAML equality rules.

On the other hand, I see no benefit but some drawback to define 
the "must-be-rejected" mapping as option 4. As I wrote in previous 
posts, the default way of evaluating equality of reference-based 
objects in many applications are based on the identity of objects. 
So, even when two mapping nodes have same tags and same contents,
sometimes, they should be evaluated to be unequal. I gave an example 
to clarify this point.

http://sourceforge.net/mailarchive/forum.php?thread_name=4AC85625.70700%40big.jp&forum_name=yaml-core

> USA:
>  Presidents: !President[]
>   - &PR1 
>     name: George Washington
>   - &PR2 
>     name: John Adams
>   (snip)
>   - &PR41 
>     name: George Bush
>   - &PR42 
>     name: William Clinton
>   - &PR43 
>     name: George Bush
>   - &PR44 
>     name: Barack Obama
>  Parties: !Party[]
>   - &PA1 
>     name: Republican
>   - &PA2 
>     name: Democratic
>   (snip)
>  PresidentToParty: &MAP
>   (snip)
>   *PR41: *PA1
>   *PR42: *PA2
>   *PR43: *PA1
>   *PR44: *PA2
> 
> Note that *PR? are the instances of President class and *PA? are
> those of Party class. The tags are resolved from the parent's
> President[] and Party[] tags.
> 
> In this example, we need some extra property like UniqueHash in
> President class just to make the YAML document to be valid. Note 
> that *PR41 and *PR43 are equal to each other by the YAML's 
> definition.

I see no benefit to reject such an input.
So, I disagree with the latter part of the option 4. 
The next simple statement seems to work well.

  Implementations "may" reject mappings that have "equal" keys, 
  according to their own *implementation-specific* definition 
  of equality.

Best,
Osamu Takeuchi


Oren Ben-Kiki wrote:
> The following issue has been raised by xitology. YAML has always defined 
> equality as follows:
> 
> 1. If the tags equal, and the content is equal, the nodes are equal. For 
> example: !!int 1 == !!int 1 ; this is the easy part.
> 
> 2. If the tags are equal, and the content is not equal, the nodes may or 
> may not be equal, depending on the tag's definition of a canonical form. 
> For example !!float 1 == !!float 1.0 but !!float 1 != !!float 0.1 ; this 
> complicates matters (requires the introduction of the concept of a 
> canonical form).
> 
> 2. If the tags are not equal, the nodes are not equal. For example !!int 
> 1 != !!float 1.0 ; this is where things start to break down.
> 
> Xitology's points are:
> 
> 1. The above definition causes an impedance mismatch between YAML's 
> definition of equality and the native data structure's definition of 
> equality. For example, in most languages, !!int 1 == !!float 1.0
> 
> 2. All existing YAML implementations follow the native data structure's 
> definition of equality and not the YAML definition of equality.
> 
> And I would like to add:
> 
> 3. The native data structure's definition of equality is typically 
> justified. E.g. most people would expect !!int 1 == !!float 1.0 and 
> would be surprised if this were not the case. However, some platforms 
> have a strange idea of equality which does surprise people (e.g., in 
> Javascript !!int 1 == !!str "1").
> 
> We have several options:
> 
> 0. Keep the current YAML equality rules, let implementations do 
> something different, and ignore the contradiction. This is obviously a 
> problem, as the spec would become irrelevant for implementers.
> 
> 1. Keep the current YAML equality rules, and change the implementations 
> to follow the spec as it is. This is a dual problem - first, it is be 
> unintuitive (people would find it surprising that 1 != 1.0); second, it 
> is impractical to implement (e.g., how do you force a Python mapping to 
> accept { 1: "int", 1.0: "float" } ?).
> 
> 2. Keep the current YAML equality rules, and redefine the tags to 
> minimize the mismatch. E.g., give up on !!int and !!float and switch to 
> !!num. This is still a problem in platforms where some nodes are equal 
> with wildly different tags (e.g., Javascript's case where !!num 1 == 
> !!str "1").
> 
> 3. Change the YAML equality rules to allow for the possibility that 
> nodes with different tags are equal. This would complicate the 
> definition of canonical form, but would allow us to better model 
> "reasonable" definitions of equality (!!int 1 == !!float 1.0). This 
> would still be a problem in platforms whose definition is "unreasonable" 
> (e.g., this would still not solve the Javascript problem).
> 
> 4. Do not specify YAML equality rules. Eliminate most of the discussion 
> of equality, canonical formats etc. and replace it by a stating that 
> implementations "may" reject mappings that have "equal" keys, according 
> to their own *implementation-specific* definition of equality. Constrain 
> this to say that nodes with equal tags and equal content are always 
> equal and hence "must" be rejected as duplicates. The problem here is 
> that { 1: "int", "1" : "string" } would work in Python and not in 
> Javascript. Arguably, anyone defining a cross-platform schema would be 
> able to "easily" avoid such issues (e.g., by requiring all keys of the 
> mapping to have the same tag, which is pretty trivial). But there's no 
> longer a universal cross-platform validity guarantee.
> 
> IMO we are being driven - kicking and screaming - towards option 4. We 
> have a precious requirement that "all valid YAML files can be read by 
> all conforming YAML implementations". As xitology points out, this is an 
> illusion, since option 4 is what all implementations do in practice. 
> Barring some creative idea not covered above (come up with one! please! 
> :-), it seems that we have to give this illusion up, painful though it 
> might be :-(
> 
> Thoughts, comments, ideas, etc. are welcome. Don't be shy!
> 
>     Oren Ben-Kiki
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Yaml-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/yaml-core


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july