[Yaml-core] Let's not get carried away

[Oren Ben-K. <or...@ri...>]

I think I missed the point of the latest ideas.

I've no problem with renaming "list" to "sequence", though I think that:

empty: !sequence

Is a bit too much. Would using 'seq' be acceptable?

As a part-time Perl programmer I've never noticed the difference between
list and array, and I *did* read the Camel book cover-to-cover. For example,
how does one declare a list variable?

Python tuples vs. lists can be neatly covered by an explicit type (as would
Perl arrays vs. lists if there is such a thing). If you feel that we should
define two additional core/common types, 'list' and 'tuple', in addition to
'seq', so be it - as long as you can come up with a good
language-independent definition of seq, list and tuple which would make
sense to, say, a Java or a C++ programmer :-)

About attaching descriptors to the top-level. That's covered in today's
spec:

!typed
- top-level list

!typed
top-level : map

!typed \
	top-level scalar

!typed top-level map key : with value

No need for magical comments.

Also, adding descriptors to the top-level prevents concatenation (unless you
allow for separators), be it using the above current syntax or using magical
type comments (Ugh!). Speaking of which, I *strongly* feel that placing
*any* standard YAML semantics in '#...' comments is a serious mistake.

Separators: I'm warming up towards the separator syntax.

- It allows safe splitting:

Note Splitting != Concatenation. Separators make *splitting* safe, in the
sense that it is always safe to textually cut a YAML document surrounded by
separators and feed it into a YAML system on its own. This is *not* true for
a top-level list entry, because it may contain references to nodes in
previous list entries. *Concatenating* is safe for both - you can always
attach another top-level list entry at the end, same as you can attach
another separated document.

- It allows for concatenation even if there are top-level descriptors.

--- !type1
...
--- !type2
...
---

- It allows us to *NOT* indent top level scalars:

--- \
Unindented top-level scalar, hurrah!
---

In fact I'd make the separator mandatory if there are top-level descriptors
or indicators (there's your place to add a YAML version if we ever need
one). I rather like this and I think that so would Brian. The beauty of it
that the above is almost exactly covered by the current spec.

Repeated map keys - I like Clark's idea of making the first key win (for
overriding configuration file entries). I think this should be reported as a
warning by the parser, however.

Indentation, I gather Brian's idea is "use tab for two 4-space levels". I
see a big problem with it. What happens when one writes SP SP SP SP TAB: is
that 2 or 3 levels of indentation? An editor/printer will display is as two,
but it would actually be three (A possibly unrelated fact is that really old
testament books were written without white space, which lends some credit to
Brian's opinion of where white space comes from :-)

At any rate, I think the only valid options we have are tabs only or 4
spaces only. Anything else is a mess. I don't care which one we choose, as
along as we inhume this vampire (chop off its head, put some dirt in its
moth, a stake through its heart, and bury it under a crossroad).

In short, I'm for keeping things as they are in the current draft. It is
better then we give it credit for. With minor changes:

- indentation (maybe),
- changing 'list' to 'sequence' (and *maybe* adding list/tuple),
- going through the production to verify the above top-level
descriptors/indicators idea works,

I think it would make for a good release candidate.

Have fun,

	Oren Ben-Kiki