Re: YAML Multi-Layer Spec

Ingy dot Net <[email protected]> Sun, 6 Mar 2016 08:14:28 -0800
Newsgroups gmane.text.yaml.general
Message-ID <CAHJtQJ6jvJn7v1Qotbivp=q4FVbKQb5rjNZt5U0eNv6SdMwp+Q@mail.gmail.com>
Most parsers in the real world use the term lexer. PyYaml is the first
place I saw the term scanner used.

On Sat, Mar 5, 2016 at 2:22 AM, Andrey Somov <[email protected]> wrote:

> Minor proposal:
> let us use 'scan' instead of 'lex'
>
> 1. I could not find the word 'lex', but could find 'scan'
> 2. scan sounds better
> 3. scanner is already used in PyYAML and SnakeYAML
>
> Cheers,
> Andrey
>
>
>
> On Fri, Mar 4, 2016 at 9:40 PM, Ingy dot Net <[email protected]> wrote:
>
>> Since this thread seems to be winding down, I've changed the subject.
>> About a year ago I was driving home from a conference where I gave a talk
>> on YAML. I had a sort of epiphany where I realized the source of a lot of
>> the contentions we had (and still have) around things like duplicate keys,
>> key order, equality and such.
>>
>> YAML processing is stack based: See the diagram in
>> https://github.com/ingydotnet/yaml-dev-kit/blob/guide/yaml-loader-guide.pod#readme
>>
>> A Load operation is:
>> (source)->read->(chars)->lex->(tokens)->parse->(events)->compose->(graph)->construct->(native)
>>
>> The YAML Spec talks about all of these things, but primarily it defines
>> precisely a token grammar.
>>
>> My big realization was that the spec needs to "spec" each layer and
>> transform. They are each distinct, and need to be defined and reasoned
>> about distinctly.
>>
>> For instance, it is not good enough to say "On input, a YAML processor
>> must support the UTF-8 and UTF-16 character encodings. For JSON
>> compatibility, the UTF-32 encodings must also be supported."
>>
>> You would want to state this in the "Reader" section.
>>
>> Statements about Key Order and Duplicate Keys can't be made about "YAML"
>> but about YAML processing at the graph layer. At the parser level there can
>> be no concept of key order or duplication. In a streaming processor, it is
>> almost certain that key order will be preserved.
>>
>> ...
>>
>> I don't think we need to be alarmed in any way. I think the spec is fine
>> for what it is. I am hoping to capture all of this in a more accessible
>> form in the dev kit <https://github.com/ingydotnet/yaml-dev-kit>. Also
>> with tests that force the issues. I think that will be much easier to
>> reason about than the spec.
>>
>> On Fri, Mar 4, 2016 at 9:04 AM, Oren Ben-Kiki <[email protected]> wrote:
>>
>>>
>>>
>>> On Fri, Mar 4, 2016 at 7:01 PM, Osamu TAKEUCHI <[email protected]> wrote:
>>>
>>>> Let me confirm one point. Does this allow identity-based
>>>> comparison of mapping nodes with some specific tags?
>>>
>>>
>>> Not sure what you mean. In YAML each mapping node has its own identity
>>> which is different from all other nodes. The only way for two mapping nodes
>>> to have the same identity is via an alias (anchor and reference).
>>>
>>>
>>>> > But that issue doesn't seem to be the one raised here;
>>>> >the problem seems to be with the "early duplicates detection".
>>>> >Which, again, is explicitly not required by the spec.
>>>> >So I'm not certain what the actual problem is with the current
>>>> >rules. Is this a case of the perceived rules being different
>>>> >from the actual rules in the spec?
>>>>
>>>> If you don't see any problem to relax the equality detection
>>>> as above, neither do I.
>>>>
>>>
>>> There's no need to "relax" it, it is "relaxed" already.
>>>
>>> Oren.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Yaml-core mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/yaml-core
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Yaml-core mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/yaml-core
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Yaml-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/yaml-core
>
>

------------------------------------------------------------------------------

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