On 16/11/01 08:53 +0200, Oren Ben-Kiki wrote:
> Brian Ingerson wrote:
> > I just finished reading the daily yaml rants. Boy do you guys sometimes
> > bore me to tears. And just when I think we've settled everything there
> > has to be new major proposals. :(
> I'm starting to feel that way too, sometimes. I've absolutely no idea
> whatsoever why Clark is trying to define a DOM, for example, or what YPATH
> has to do with things :-) I mean, it is all well and good to debate what the
> base class of map and list would look like and whether the return value of
> atom is a 'void *' or a 'wchar_t *' or whatever, but *why bother*?
> We have an info model we all agree on (never mind the fact that it can be
> worded in any of several ways, all meaning basically the same thing). We
> pride ourselves on it being supported *directly* by every programming
> language. Let's just leave it at that, OK?
> > My thoughts:
> > - I withdraw my "last key wins" proposal
> > - || is fine
> > - I want --UNIQUE instead of just ---
> > - I don't still don't feel like answering \$a->
> > - No forward references please
> We all agree so far.
> > - I really want to table "structured keys" until YAML 1.1
> I have a problem here (see below).
> > - I really want to *IMPLEMENT* now!
> I agree. That's why I have a problem with the previous point :-(
I guess I was just too tired and cranky to want to deal with structured keys
last night. I talked to Prescod later. He confirmed that Python can use
anything as a key, so I guess we need to do it. See below.
> > My rants:
> > 2) In Perl, YAML will never *really* round trip in memory structures. So
> > I'm not super worried about edge cases. Consider a string that is
> > readonly. A constant. Upon roundtripping, it will not be. And that's
> > just the tip of the perlberg. So just relax. I do have a very good
> > idea of how I'm going to serialize Perl in YAML. But explaining every
> > edge case at this point is futile. <subrant> The examples I get from
> > you guys are somewhat problematic and have subtle issues that I
> > really don't feel like discussing at length.</subrant> I'd rather be
> > in the position of you guys saying, "Hey Brian, why does YAML.pm do
> > this?". Will I ever get to write a YAML.pm?
> OK, point taken. One point though - we want the Python or Java
> implementation to be able to read whatever YAML.pm produces and result in
> reasonable, *native* structures. We'll have a hard time if the magic you'll
> use to serialize read-only strings (or whatever) would mean that reading
> them into Java I'll have to use YAML-specific classes.
I think you misunderstood me. I was saying that I have no intention of making
YAML round trip Perl data structures bit for bit internally. That would be
nigh impossible. There are too many optimizations etc. I will just make YAML
the best (most useful) serialization module available.
> Which brings me to structured keys. I want to do the Java implementation. I
> *really* would like to do it by latching to Java's serialization mechanism,
> so you could just serialize your data into YAML. Some people already did it
> using XML, I thought I could start with their code, change the formatting,
> and make YAML a nice way to serialize any Java data.
> The problem is Java hash tables. They can take just about anything as a key,
> as long as it has a hashCode method (just like Python). I have written quite
> a bit of Java code which used this - it isn't esoteric at all to a Java
> I realize Perl would have a hard time with these. For all I care, just
> reject them as unsupported. But I need them, sorry. Other than that I agree
> we should just wrap things up.
> Now, about these keys :-) For some reason Clark doesn't want to have
> separate @ and % indicators for the separate map and list "styles". As he
> put it:
> > To cut to the chase...
> > % !array
> > 0 : val
> > : one
> > @ !array
> > - val
> > : one
> > How are these different?
> Sigh. In the same way that the following are:
> one: \
> two: \\
> The kind/style of the node is different. *And this kind/style is not
> reflected in the data model* in both cases. Big deal. I think keeping "one
> indicator <-> one kind/style" makes a lot of sense. Besides, I think:
> empty-map: %
> empty-list: @
> Is neat. It also helps Brian in his blessed-empty-collection use case (not
> such a big deal, he can manage without it, but it does help). It is
> especially useful at the top level, where it *really* simplifies things *a
> lot*. No more "you can have an empty top-level plain scalar as long as the
> optional type property exists" - Good riddance!
I don't like it. We worked hard to get rid of those. It really irks me to see
them again. Plus it raises all kinds of questions about how to serialize a
typed empty seq and use it as a map key.
I think we need a structure key indicator. I'll explore this in response to
> Agreed. Now if you just give me my hash table keys I'll start happily
> working on the Java code :-)
Can I quote you on that? Stay tuned then...
> I suggest we declare that next weekend, come hell or high water, we freeze
> the spec and start coding.
Frozen high water in hell? Great! Let's do it!