Re: [Yaml-core] Ideas to Shoot Down

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

On 14/03/03 12:53 -0700, ms...@oz... wrote:
> Steve wrote:
> > Clark talked me into the fancy iterators for PyYaml, but it's a pretty
> > superficial use of iterators.  If you have a stream with multiple
> > documents, the documents are parsed one by one, but it's not any finer
> > granularity than that.  You can get the documents one by one with
> > iterator calls, but you can also get them by normal method calls.
> >
> > I have used YAML a lot, and it's always for relatively small files that
> > I just bring into memory all at once.  The iterators haven't given me
> > much utility, and the interface just confuses some users.  YMMV, of
> > course.
> 
> What the iterators give is flexibility.  You want a list?  You want each
> document one by one?  You want a special configuration document first,
> then the rest as a list.  The iterator does it all.

Yep. My new design still has the Load() function return a list. But it
uses an iterator to do it now. And the iterator is, of course, part of
the pulic interface. In fact, here is the exact code for YAML::Load:

    sub Load {
        my $self = YAML->new->_set_loader_attributes;
        $self->loader->parser->string($_[0]);
        my @data;
        while (my @next = $self->loader->next) {
            push @data, @next;
        }
        return wantarray ? @data : $data[0];
    }


> > I am amazed at how much utility I get out of the current version of
> > PyYaml, which has a boring architecture, a mundane interface, and few
> > bells and whistles.  I wish PyYaml were even simpler.  I got burned on
> > the implicit typing of dates last night, when I just wanted the damn
> > things to come in as strings.
> 
> I downloaded the latest version yesterday and it dropped into my
> application fine, although it did force me to remove trailing spaces from
> my values.  One thing I would have liked was a syntax validator that would
> show all the errors at once rather than aborting at the first one.

That could be tricky. But possible. You need (theoretically) a
recoverable parser. I can think of many parse errors that are
recoverable:

    - [foo, bar]
    - [foo, bar
    - [foo, bar]

You don't have to kill the parse on line 2 because the indentation lets
you know you're done anyway.

> If Ingy and I ever get the next version of PyYaml finished, the first
> feature it will have is an "all values are strings" loader.  

A standard, non-schema aware Loader should always load values like these
as strings. If you want dates as objects, just mix in a date loader
class.

This is now possible, because types are out of the spec. They don't need
to be recognized by the parser. This was the smartest thing we did for
simplfying YAML logic.

> That's the biggest thing preventing me from deploying it more widely:
> having to give others elaborate rules about the value syntax. It's
> easier to say, "Just start your value with an alphanumeric character
> and you'll be OK," than to say, "All digits bad. YYYY-MM-DD bad.
> Starting with !'"% bad. t/f/~ bad."

Yeah. This just isn't the case anymore. Basically every scalar is parsed
as a string with a type. And (in the absence of a schema) it is
completely up to the Loader as to what to do with that string and type.
Loaders are *encouraged* to support the YAML type repository, if and
when it makes sense. And most of the time it makes sense to load values
as strings by default, and load dates as objects when the user has the
load_dates_as_objects option turned on.

Even plain scalars have a type. The type is the empty string. Which is a
cue to the Loader to do what makes most sense, based on the Loaders
defaults, the Loader options set by the user, or by the typing hints in
a Schema document.

It turns out that the following equivalences hold:

    # Empty types
    - 3.1415
    - ! 3.1415
    # String types
    - '3.1415'
    - !str '3.1415'
    # or
    - |-
      3.1415
    - !str |-
      3.1415
    ...

As an optimization, parsers must pass back quoted scalars with the type
'yaml.org/int'.

I don't know if the 3 callaberos ever explained it to the list really
well. I think we were so tired from battling the issues leading up to
this understanding, that we never really gave a full synopsis to the
mailing list.

Cheers, Brian

PS forwarding to the mailing list, because it's relevant.