On 07/11/01 09:27 -0500, Clark C . Evans wrote:
> Ok. Let's call our list construct a "sequence".
Interesting. My friend Neil Watkiss suggested the same word yesterday. He
knows Perl and Python inside out BTW.
> >From examination of your construct below, I think
> "dunno" in Python could be the fabled tuple. The
My other friend Neil Kandalgoankar said they are similar but not the same.
To me, a Perl list is not a structure at all. It's not something we need to
serialize in YAML. It's just a way of saying: "This bunch of things".
My concatenation needs stem from this:
I simply want to put any number of YAML nodes into a single document. They
should actually be autonomous. References in one should be invalid in
another. I don't want to wrap them with another data structure. And I want to
be able to easily concatenate any group of YAML documents into a single
document. And then be able to easily split them apart again.
It seems that a separator-based syntax is the way to do it. If we can't do
this, then let's just say: "One node per file. You can try to concatenate
list node files, but you won't be able to split them out again".
As for tuples, I just want to keep them as is. Python data structures
serialized like this:
Paul Prescod suggested a really cool way to round trip them through Perl.
Instead of wrapping them with a hash which would make them hard to use, we
can just bless an array with the string 'org.yaml.tuple'. That way we can use
it as a normal Perl array. Cool huh. This actually has very big implications
for other things. Yay.
> | a scalar
> Hmm. Do we require scalars to be indented
> just for good measure?
> a scalar
I'd really like to be able to not indent single line scalars. I think we can
avoid it. Remind me again why we can't.
On 07/11/01 10:28 -0500, Clark C . Evans wrote:
> A. Since list is used by Perl and Python to
> mean two different things, we adopt "tuple"
> from python and "array" from Perl. Let us
> call these classes org.yaml.array (!array)
> and org.yaml.tuple (!tuple).
OK. For those specific structures. Like,
> B. We call our sequential yaml construct (-)
> a seq(uence). And we call our functional
> construct (:) a map. Thus the word "list"
> is no longer part of the YAML vocabulary
> to reduce confusion.
OK. I like the abbrev.
> C. The starting production is map xor seq.
> A YAML text may not begin with a scalar,
> however, a YAML text can begin with a
> one-tuple... which is damn close.
> D. The default class for a top level sequence
> is a !tuple and the default class for
> secondary and further indented sequences
> is an !array.
Huh? no thanks. tuples should just be rare python things.
> E. Please note another whitespace option as motivated
> by Python . This solution allows mixing
> of TAB and increments of 4 SPACES as follows:
> 1) On parse, a tab is replaced (from left to right)
> by four or eight spaces such that the total
> number of characters up to and including the
> replacement is a multiple of eight.
> 2) Each sequence of four spaces becomes an
> indentation token.
> In this way, one can think of a TAB as a
> double indent. On the down side, one must
> either use all spaces or tabs and spaces.
> One cannot exclusively use TABS with this
> solution. More thought, no?
This is one of the solutions I was going to propose, based on my talk
with Paul. Another one that I'd really like to consider in full is using
a single space indent. Please give it some serious thought before
screaming bloody murder.
On 08/11/01 11:15 +0200, Oren Ben-Kiki wrote:
> 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
> how does one declare a list variable?
List isn't a type, it's a context. Almost every operation in Perl can have
either a list or scalar context. I just want to be able to put more than one
autonomous thingy into a YAML file. It's *not* the same as a YAML list. A
YAML list (or whatever) *is* a type and that type gets parsed into a Perl or
> About attaching descriptors to the top-level. That's covered in today's
> - top-level list
> top-level : map
> !typed \
> top-level scalar
> !typed top-level map key : with value
> No need for magical comments.
> 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
> 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.
> 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).
Interestingly, Paul Prescod ( a huge Python bigot ) doesn't really even like
indenting. He didn't really have any good suggesstions for us on that front.
> but it would actually be three (A possibly unrelated fact is that really
> testament books were written without white space, which lends some credit
> Brian's opinion of where white space comes from :-)
> 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 sencond that for the most part. I'm still reading, but I like what I see.
On 08/11/01 17:03 +0200, Oren Ben-Kiki wrote:
> Or, for that matter, a '---' :-) Also note that using a '---' you wouldn't
> need to indent the scalar!
That's what I've been saying.
I would still indent multilines so that long keys would not require
> Back references are not allowed to go across '---' for safe splitting.
I completely agree. If they are important then wrap them in a sequence.
On 08/11/01 10:24 -0500, Clark C . Evans wrote:
> Ok. So a YAML document is a series of fragments.
> And each fragment is a map, seq, or scalar? This
> is a change to the information model... I'll go
> with it if Brian agrees.
I think we're coming together now.
On 08/11/01 18:24 +0200, Oren Ben-Kiki wrote:
> I prefer the current draft wording. A YAML stream is a series of YAML
> documents, each document being a map, sequence or scalar. This leaves the
> information model untouched.
> > | I'll go
> > | with it if Brian agrees.
I'm not done reading the arguments, but I gotta run to make my call with