On Tue, Mar 12, 2002 at 04:14:15PM +0100, Rolf Veen wrote:
| Functions are a special class of binary relations. If you define
| a format for binary relations in general, you will never have the
| chance for such a discussion in the future. And that at the cost of
| nothing: you already have the syntax.
I understand your perspective, but just beacuse we can do it
does not mean we should. A few factors weigh-in heavily:
1) Most programming languages have built-in list and map
datastructures. Some languages (C,C++,ML) may only have
"static" maps (aka structs or records), but with a fixed
schema this is good enough, and often those languages have
a well known hash construct. If a language doesn't support
maps or lists, then support is usually easy to find.
2) While your statement is true, a bulk of mathematics (90%
or more of real analysis theorems) require functions. The
same with most computer algorithems, they require functions
(and usually only functions) to operate. Thus, by sticking
with functions we don't have to deal with cases where the
data is non-functional, and thus a great many results are
immediately available. For instance, one could generate a
composition function over yaml texts that is transitive.
Relations in general do not have these properties. Thus,
by restricting our information to functions we make it
much easier to define operations on YAML information in a
3) As a pratical example of #2, since YAML containers are
functional, any YPATH such as /x/3/y/z will return at most
one node. Thus, all of the logic to differentiate between
"sets" of nodes and nodes is not needed for cases like this.
In practice... this is huge. Play with the DOM some and
you will see all kinds of quirks and hacks to get data which
"could be a list but isn't" to work in a functional way.
4) Functions (maps,lists) are the 80/20 rule. At least 80%
of the time it is exactly what you want, and in the cases
that it's not (far less than 20%), you can simulate what you
need very easily. And unlike relations, maps/lists are very
powerful abstractions due to the rich mathematical properties
that emerge from the functional constraints.
5) If we use a maplist structure, then this will require a DOM
(third-party data object) in most languages, like XML. IMHO,
this is a show-stopper. Alternatively, one could use an
alternating map/list structure. However, such a structure
is not very usable by your average programmer; thus a custom
construct would be needed.
6) We debated long and hard as to how we can make the syntax
less painful for those people which want a namedlist structure,
and the "- key : value" syntax construct is the result. This
was the work of alot of compromises and consessions on many
sides of the isle. Thus, for listmaps.
7) Modeling relations is one step closer to the "namedlist", which
is a list of ordered pairs (key,val). This is the fundamental
XML construct and is not supported by any language natively.
It's also a pain to work with programmatically. This structure
works great for mixed-content.
8) If you want mixed-content, use XML. XML excels at mixed-content.
We are trying to provide a simple serialization for native data
constructs; not a document (aka mixed content) markup language.
| I do insist, for the last time, to open the specification to generic
| binary relations. It can only bring more users to YAML, never less.
I totally disagree. Doing this will complicate everything and provide
very little benifit. Just beacuse the syntax requires no modification
to support this doesn't mean that the API and dependent libraries are
not signficantly impacted. And IMHO, this impact just isn't worth it.
That said, I hope for your continued support in YAML; this just
happens to be one of the cornerstones that I think we need to
stick by. We are not making this decision blindly it is the result
of many (at least two years) discussion on SML-DEV.