Re: minimal YAML recommendations?

On Fri, Jan 30, 2015 at 10:21 PM, Oren Ben-Kiki <[email protected]> wrote:

> On Sat, Jan 31, 2015 at 1:01 AM, Ingy dot Net <[email protected]> wrote:
>
>> Hi mofo,
>>
>> Oren, I always consider the 3 main additions from JSON to be:
>>
>>    - Types (Tags)
>>    - References (Anchor / Aliases)
>>    - Keys (can be any node, not simply strings)
>>
>> Also:
>>
>>    - Multiple documents per file/stream.
>>
>> Those are all model changes. The major syntax changes are:
>>
>>    - Block form (no {} [])
>>    - Quoting styles (esp NoQuotes)
>>    - Comments
>>
>> Yes, I was sloppy. I packed all the model changes together as
> "deserialization control". You are of course correct.
>
>> The YAML spec is a little over complicated but I started this wiki to
>> discuss making YAML 2.0, simply be a reduction of the current YAML:
>> https://github.com/yaml/YAML2/wiki#yaml-20-proposals
>>
> The main one is getting rid of the folded scalars. Merging it with the
> quoted one is an interesting idea.
>

I actually had the rare chance to talk to Clark on the phone yesterday
(about a DNS issue) and he mentioned making heavy use of the folded form in
some stuff he was doing. I'd like to see some of those files. :)


> There are quite a few documents on the net that people base modern
>> implementations on taht should probably be removed. People end up all over
>> the place on default schema (typing of unquoted strings). eg the string
>> *Yes* being loaded as a boolean. http://yaml.org/type/bool.html is the
>> culprit. Sometime after we published this we agreed that by default only
>> (true false null) and unquoted numbers should be loaded as non-strings.
>>
> Yes. We got rid of all that in 1.2 but I guess the habit stayed...
>

Well, and the documents. I'm going to be going over what things we have
published soon. We can discuss taking some of that offline.

> In YAML, any node can be loaded as almost any object. It all depends on
>> the "schema" being used. We've been bad at making a best practices
>> document. In general, people make implementations where the schema is at
>> least agreed upon within the Load/Dump functions of that particular
>> framework. In a better world:
>>
>>    - there would be a clear default schema
>>
>> I think the 1.2 spec provides a clear default schema...
>
>>
>>    - all implementations would adhere to it by default
>>
>> There's the rub.
>
>>
>>    - we would have a schema language
>>
>> Yes, that would be nice. There are JSON schema proposals, ideally we
> should superset them.
>

Do you have any favorites? URLs?


>
>>    - implementations would be schema aware and have the ability to
>>    load/dump accordingly
>>
>> In the Perl world there exists a YAML::Tiny, which is a
>> non-yaml-core-approved but heavily used and useful thing that is the spirit
>> of this topic. It's doc has a mini spec:
>> https://metacpan.org/pod/YAML::Tiny#YAML-TINY-SPECIFICATION
>>
> It would be nice to update it to be 1.2 compatible; that would allow it to
> use bool, for example, and I think resolve some of the other issues.
>
>> I started a parser generator project called Pegex that is easy to port to
>> any language that has regex support. The primary idea is to make grammars
>> that are really easy for people to read and maintain, and that create
>> parsers in 20 languages at once. Here's a Pegex grammar for JSON and also
>> JSONY (a JSON variant I helped create):
>>
>>    - https://github.com/ingydotnet/json-pgx/blob/master/json.pgx
>>    - https://github.com/ingydotnet/jsony-pgx/blob/master/jsony.pgx
>>
>> These grammars have released implementations. My unfinished goal is to do
>> a YAML grammar for Pegex, so at least we can have a set of implementations
>> based off the exact same document.
>>
>  Not sure I follow the syntax there. The main PITA in the YAML spec is
> that we can't use INDENT/UNDENT because of the way that '- ...' behaves.
> Explicit keeping track of indentation then becomes an issue.
>

Yeah you nailed it. That's the hard part, although I have some ideas of how
to build it into the grammar (involving grammar variables and actions that
set them, effectively modifying the grammar).

re Pegex syntax… this:
https://github.com/ingydotnet/json-pgx/blob/master/json.pgx
compiles to this:
https://github.com/ingydotnet/json-pgx/blob/master/json.pgx.yaml
which is essentially a tree of regexes.
The Pegex grammar for Pegex is here:
https://github.com/ingydotnet/pegex-pgx/blob/master/pegex.pgx
with the yaml compilation unit next door.

> If you'd like to chat more, find me in #yaml on irc.freenode.net
>>
> It has been dead for so long... What is your time zone these days? I'm in
> Israel.
>

Well yeah. I hang in there and field questions, but not much excitement.
I'm in Seattle again.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core