Wrong YAML nil serialization and scalars deserialization

[olbat]

Crystal's YAML builder/parser does not handle properly nil serialization and YAML scalars deserialization:

• Empty strings are serialized to nil
• null, bool, float and timestamp scalars are deserialized to strings

Here is an example:

$ cat test.cr
require "yaml"
p "".to_yaml
p [""].to_yaml
p({"a" => ""}.to_yaml)
p YAML.parse("---")
p YAML.parse("~")
p YAML.parse("null")
p YAML.parse("- ")
p YAML.parse("a: ")
p YAML.parse("true")
p YAML.parse("yes")
p YAML.parse("on")
p YAML.parse(".inf")
p YAML.parse(".nan")
p YAML.parse("01:01")
p YAML.parse("1970-01-01")

the output:

$ crystal run test.cr | nl
     1	"--- \n...\n"
     2	"---\n- \n"
     3	"---\na: \n"
     4	""
     5	"~"
     6	"null"
     7	[""]
     8	{"a" => ""}
     9	"true"
    10	"yes"
    11	"on"
    12	".inf"
    13	".nan"
    14	"01:01"
    15	"1970-01-01"

$ crystal --version
Crystal 0.21.1 [3c6c75e] (2017-03-06) LLVM 3.5.0

to compare, the output of Ruby's implementation:

$ sed 's/parse/load/' test.cr | ruby | nl
     1	"--- ''\n"
     2	"---\n- ''\n"
     3	"---\na: ''\n"
     4	nil
     5	nil
     6	nil
     7	[nil]
     8	{"a"=>nil}
     9	true
    10	true
    11	true
    12	Infinity
    13	NaN
    14	3660
    15	#<Date: 1970-01-01 ((2440588j,0s,0n),+0s,2299161j)>

$ ruby --version
ruby 2.1.5p273 (2014-11-13) [x86_64-linux-gnu]

edit: deserialization of every YAML scalars seems to be impacted

[olbat]

I'm not sure it will be useful to fix the issue but here is the Ruby's Psych scalar scanner implementation.

[asterite]

This is more or less a duplicate of #4175 . The current YAML parser only knows about String, Array and Hash. We need to extend this to support the core YAML schema, possibly other schemas too.

[refi64]

@asterite Did you mean #2873 or #3101? Right now, your link is giving me a recursion error...

[olbat]

Oops, I tried to find a related issue but I missed both of them, thanks for the references.

[straight-shoota]

This issue can't possibly be a duplicate of itself and I don't think it is a duplicate of #2873 or #3101 either. Please reopen.

[ysbaddaden]

No. It's a duplicate of #3101 per "unsupported types (e.g. null, numbers)".