Re: [Yaml-core] Quick List

[Brian I. <in...@tt...>]

On 06/11/01 10:31 +0200, Oren Ben-Kiki wrote:
> Brian Ingerson [mailto:in...@tt...] wrote:
> > > Since we will have indented for top level scalars,
> > > why don't we just use list xor map as the starting
> > > production?  
> > 
> > Indented is just for multiline. We can still have:
> > 
> > foo
> > ---
> > This is cool
> > ---
> > 3.1415926
> > ---
> > !bigint 999999999999999999999999999999999999999999
> > ---
> > "I love\nYAML!"
> 
> This doesn't work. Consider:
> 
> ---
> What's this: then?

Definitely a map. Right?

> ---
> "How about this
> very long
> ... x 1000000
> scalar"
> ---
> "It could easily
> have been a long
> ... x 1000000
> key" : So unbound lookahead. No way!

Interesting. But we could easily allow it as a very rare case. Unbounded
lookaheads are by no means hard to implement. Especially in this context.

> ---
> 
> I think we must indicate and indent top-level scalars, period:

Well I can live with that I suppose. Especially if we don't allow a
separated series right now. Being stricter up front is not a problem.

> 
> ---
> \
>       "This is a
>       long ...
>       ... value"
> ---
> "this is a
> long ...
> ... key" : with a value
> ---

OK. At least for now.

> 
> > > If someone wants a log file, then they
> > > should use the list as the starting production
> > > and use the list for all of the items appended.
> > > If someone wants a configuration file, they can
> > > use a map as the starting production.  You don't
> > > usually concatinate maps... so no big deal.
> > 
> > You can use list in this way now. Please feel free to do so...
> 
> A classic Perl vs. Python philosophy disagreement: "There's more then one
> way to do it" vs. "This is the way to do it". Hmmm...

Go TMTOWTDI!!!

> 
> > ... I reallly want a series of mixed type nodes. This 
> > provides the most flexibility. It's the way all other Perl
> > serializers work. I *really* want this.
> 
> OK, now we have a real use case we can sink our teeth into. I gather the
> issue is:
> 
> $file = open_file;
> dump_as_yaml($file, $obj1);
> dump_as_yaml($file, $obj2);
> 
> Correct?
> 
> Some points:
> 
> - Let's look at how the file looks:
> 
> As a top-level list:
> 
> -
>       obj1_member1: value
>       obj1_member2: value
> -
>       obj2_member1: value
>       obj2_member2: value
> 
> The above assumes that dump_as_yaml always writes the object as a list
> entry, which seems a reasonable thing to do given that "dumping" should
> allow for multiple objects. Using separators:

This logic is poor because "What do you do when dumping a series of one
object?". Do you use list or scalar? If you don't coerce it into a list of
one object, the parsing person will have to use different code for one vs
multiple objects.

If we are going to do lists, then the user must do it herself:

    # Dump a list of one object
    dump_as_yaml($file, [$obj1]);

> 
> ---
> obj1_member1: value
> obj1_member2: value
> ---
> obj2_member1: value
> obj2_member2: value
> ---
> 
> So, in one option the keys are indented, in the others they aren't. It
> doesn't seem like such a big deal to me. Let's see if there's any technical
> issues...
> 
> - Suppose obj1 and obj2 share references to the same sub-structures. Do you
> want to be able to reference back from obj2 to the nodes of objs1? (Java
> allows one to do that when serializing multiple objects to the same stream).
> 
> Using a separator: You can't, the wording says "independent document".
> Using a top-level list: You obviously can.
> 
> Hmmm. This may actually give a good reason for having separators. Not so
> much for concatenation, but for *splitting*. It is always safe to split a
> YAML file on a separator. It is not always safe to split it on a top level
> list entry.
> 
> Given this distinction and the fact Brian really wants it, I'd say let's
> keep it in.

Now you tell me. :)

Well I've said my peace. (for today)

Lemme know...

> 
> If the above (indicated top-level scalars, using separators as safe split
> points) is acceptable to you both, that leaves us with just one open issue:
> indentation (There's also Clark's syntax modules idea, I guess, but that
> seems a bit far-out to me right now).
> 
> I rather like tabs (I love the way I can tell my editor to display them at
> different widths, that's very useful). But I can live with 4 spaces. Clark
> wants 4 spaces but can live with tabs. The ball's in Brian's court - and any
> inputs from Paul would also be appreciated.

I'll give more on this later... but consider

- YAML is human friendly
- Whitespace is *not* human friendly

Whitespace is an evil conspiracy handed down to us by Satan. That much I
know. People don't grok whitespace implications. And if they do they
probably don't want to unless their name is Guido (or Satan).

---

Here are a couple facts:

1) YAML's block syntax requires an exact, preknown indentation amount.
Autodetection/Switching is not an option.
2) Most programs process tabs as meaning the nearest 8th column, or 8 chars.
3) Almost all Perl core and CPAN code uses 4 column ident. (usually mixing
tabs and spaces) Prescod confirms that it is the same with Python.

You can guess where I'm headed. More later...


Cheers, Brian