Re: Equality

Oren,

>     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.
> 
> 
> Not that exceptional; it is also true for Python, for example.

I do not think there are so many languages that do not distinguish
1 from 1.0 in the latter meaning. I do not think there are so many 
applications that utilize the equality of 1 with 1.0 as mapping keys. 

> identity-based mappings). If "a few" applications in "a few" languages 
> are forced to add "some" overhead (such as unique hashes to the example 
> above), so be it.

On the other hand, I know many languages that can compare objects 
by their identity. I know many applications that make use of 
equality evaluation of objects by their identity.

I feel that your opinion is a little biased.


> I'm not convinced by this example. It seems to me this is the same 
> president, and should justifiably belong to just one party. I suspect 
> what you call "President" is actually a "Term in Office" where one of 
> the properties is the actual president name (other properties would be 
> date, or whatever). But that's neither here nor there; granted some 
> languages would allow the above (at the native data structure level).

I just wanted to point out that a hash object in the real world 
sometimes contains multiple objects as keys that have exactly the same 
property values, and such a data structure does not always loose its 
meaning after the serialization. The meaning of the data nodes in a 
YAML document should be given as the schema, either implicitly or 
explicitly. I thought you can see the meaning of my example withtout 
an explicit schema but it was wrong. 

The schema in this case would be:

  A President object represents an individual president. 
  The Presidents array represents the order of the presidents.
  ...
  (snip)
  ...
  Presidents can belong to different parties even when they have the same name.
  ...
  (snip)

We can look in this dataset to find the name of the 41st president
of USA and the party he belonged to. This must be able even when 
some of the different presidents have the same name.

  president41st = USA.Presidents[41 - 1];
  president41st_name = president.name;
  president41st_party = USA.PresidentToParty[president];

We can also check if one individual person has ever became the president 
multiple times or not. I mean we should be able to check if the 41st 
president and the 43rd president are the same person or not.

  if( USA.Presidents[41-1] == USA.Presidents[43-1] )
    print "He became the president twice!!\n";

I think such a dataset is useful enough to be stored in a YAML stream.


> I do see a benefit. I think our goal was (and should still be) more 
> towards portability and we should only make compromises where we have no 
> other option. The above case, IMO, is an example where we made the right 
> call. We picked a highly portable, highly useful subset to support. 
> Specifically, identity-based mapping were intentionally considered to be 
> outside the "least common denominator". The benfit is that, if every 
> valid YAML file has "different" keys (different in tags and/or values), 
> then these files would work in all languages (whether or not they use 
> identity-based mappings). If "a few" applications in "a few" languages 
> are forced to add "some" overhead (such as unique hashes to the example 
> above), so be it.

> As xitology demonstrated, we haven't got as close to the "100% 
> portability" as we thought we had. Ideally, I would like to do is to 
> keep "a valid YAML file is acceptable to every implementation". That is, 
> instead of making YAML more relaxed, I would make it more strict - e.g., 
> disallow { 1: a, "1": b } in _all_ implementations.
>
> However, there simply does not seem to be any practical way to define 
> such a safe "strict" rule, given all the different languages and tags 
> out there. So, we are forced to relax the rules instead ("being dragged, 
> kicking and screaming" :-). I would like to minimize the amount of 
> damage (to portability); that is, since I see relaxing the rules as a 
> necessary evil, not as a desirable goal by itself, I would like to keep 
> things as strict (that is, as portable) as possible.

I do not find very much importance to keep an arbitrary YAML 
file to be acceptable to every implementation. Each YAML file 
must have its own purpose. So, I expect no chance where one 
would like to feed the YAML file in my example to any YAML 
implimentation that do not have reference-based object model.

IMO, the main purpose of defining the semantics in YAML spec is 
to make the YAML file readable by human eyes. If we can believe 
the order of mapping keys is always neglected by the YAML processor, 
it becomes easier to understand the meaning of the data model and 
to hand-write a YAML file.


> We could have gone another way. We could say that "YAML semantics is 
> whatever the language makes it to be", define no constraints about 
> equality, and while at it, allow YAML mappings to consider key order 
> (which would make the PHP people happy), and so on. This would make each 
> language-specific YAML implementations simpler, and "generic" 
> implementations harder; it would also reduce YAML's usefulness in 
> cross-platform use cases. This way is not what we set out to do when we 
> started the YAML project, and I still believe that we made the right 
> call, even if we need to adapt our lofty ideals to the cruel reality :-)

So, I do not like to define the must-be-rejected mapping as you proposed 
because it does not seem to make YAML files much more readable. I think 
it is more benefitial to remov the constraint and to increase the 
adaptablity of YAML language to more applications.

Actually, the definition of YAML's equality seems currently almost 
always neglected by real implementations. We should reconsider what 
is the real requirement for YAML language in the majority of the use 
cases.

On the other hand, repeatedly, I do not want to allow representing 
PHP's ordered-hash by a YAML's mapping node. It will decrease the 
readability of a YAML file. I prefer to believe that the keys 
in a mapping node can always be written in an arbitrary order.


BTW, I want to distinguish the language-specific definition for
equality from the application-specific (schema-specific) one. 
Often, the native objects for a data model overrides their 
equality evaluation operators to behave as same as the data model. 
In such cases, the language defalut evaluation is identical
to the application specific one. However, even when the language
default evaluation can not be overridden, if the application 
have to deal with a data file that contains data nodes with
some specific equation definition, the application should 
evaluate the object as written in the schema.


In summary, let me list the four issues related to the current 
discussion.

  (1) Equality of scalar nodes: 1 == 1.0 ???
  (2) Equality of mapping nodes with user-defined tag:
        !President { name: "George Bush" }
  (3) Allowing duplicated keys in one mapping node:
        { a: 1, a: 2 }
  (4) Representing PHP's ordered-hash by a mapping node:
        !PHP_Hash { key1: value1, key2: value2 }

My opinions are:

  (1) An application specific definition should be allowed.
  (2) An application specific definition should be allowed.
  (3) Allowing an application specific definition does not
      seem to be bad idea but I do not have a concrete 
      opinion for it yet.
  (4) Key order in YAML mapping node should be always meaningless.

Best,
Osamu Takeuchi

------------------------------------------------------------------------------
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