[Yaml-core] Sunday Meeting Minutes

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

Oren,

Clark and I met on IRC for a while. Here is what we came up with:

0) I propose that '...' is our new way of indicating end-of-stream in
   our communications only. It is not intended to ever be part of YAML.
   Also, starting with '===' means "no header".

0b) Question: Is '---' called a "YAML Separator" or a "YAML Header"? I
    vote for header. If so, we should update the doc.

BTW, I have updated 'ysh' to understand '...' and '==='.    
   
1) Inline values are still not allowed at the top level, *except* for
   the empty string. This allows:

--- !seq
...

to work. 

1b) Clark proposed the exceptions

--- []
--- {}
...

but I am against them for consistency sake.

2) The new proposed syntax for explicit transfers is
   '!type.subtype;format'. Examples:

---
- !binary;base64 SHFFF3F8F3QHFWDFKB=
- !int.I64 25797537
- !int.I8;hex 1f
- !int 2974973498749849328473274974934732947274
...

2a) A Parser cooks the format and only reports back the type/subtype and
    the string value (or the binary value for binary data).
2b) All implicit casting is done at the Parser.
2c) I8, I16, I32, and I64 have been added as integer subtypes.
2d) A Parser must detect and error on an out-of-range explicitly
    subtyped integer. typed/subtyped integer.
2e) There is no implicit determination of integer subtype. For example:

---
- 42
- 999999999999999999999999999999999
- !int.I8 42
...

These will be parsed as:

('org.yaml.int', '42')
('org.yaml.int', '999999999999999999999999999999999')
('org.yaml.int.I8', '42')

A Loader (by default) must roundtrip all of these. 

2f) A useful Loader option might be:

$YAML::UpgradeInteger = 1;

2g) A 'bigint' or '!int.big' type is not needed, since just 'int' will
    do the right thing.

2h) '!int' (implicit or not) is the general use case. But the I##
    subtypes may be desirable in some applications.

3) YAML.pm will not deal with these new issues for its maiden release.
   They will be documented as known deficiencies.

3a) Oren's new proposal of inline singletons was not discussed. This
    requires another meeting, with Oren of course. I like the simple use
    case, but I'm wary of the big picture implications, and I'm loathe
    to implement it the short term.

Cheers, Brian