Re: Next YAML: drop equality definition

On Wed, Mar 9, 2016 at 7:55 AM, Osamu TAKEUCHI <[email protected]> wrote:

> I want to know the reason why non-preservation of scalar identity is
> allowed in the spec.

The design goals for YAML are, in decreasing priority:

1. YAML is easily readable by humans.
Having scalars-with-identity is not what humans expect. Humans _tend_ to
perceive scalars as "just values" and collections as "something with
identity".

2. YAML data is portable between programming languages.

Different applications can apply a different schema to the same document.
If these schemas differ on assigning identity then you cause all sort of
sticky issues.

3. YAML matches the native data structures
<http://www.yaml.org/spec/1.2/spec.html#native data structure//> of agile
languages.

Which tend to make scalars immutable. Even Ruby is starting to see the
error of its ways here so it is moving to make at least some strings be
immutable (literals, "frozen", etc.).

4. YAML has a consistent model to support generic tools.

I guess the question is, how strong is that consistent model? What does it
_allow_ generic tools to do? The rules about scalar identity give generic
tools the ability to do more than they could do if scalar identity had to
be preserved. Note that a human with a text editor can also be a generic,
schema-blind tool.

5. YAML supports one-pass processing.

That's irrelevant to the topic at hand. I think.

6. YAML is expressive and extensible.

You could argue that not preserving scalar identity requires a more
cumbersome expression of some native data (e.g. wrapping a scalar in a
collection "just because" you want to ensure its identity is preserved -
similarly to having to use an !!omap instead of the cleaner map syntax for
PHP dictionaries). "Everything" still _can_ be expressed, though.

7. YAML is easy to implement and use.

I don't see it applies here. At any rate, being the last goal, it tends to
lose out - which is the main issue people have with YAML.

So... it seems to be a reasonable decision given our goals.

One of the reason we explicitly listed the goals, _in order_, was to break
ties when different goals pushed us in different directions. Order the
goals differently, and you'll get a different spec. I think you would end
up with JSON if you ordered them in a different way. Or even, god help us,
XML ;-)

Oren.

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core