Hi, I'm not sure this is the right place to report issues about Syck but that's the best I've found so far :) I think I've found a problem with the way Syck quotes strings that could look like floats. Here is a short example: irb(main):001:0> require 'yaml' => true irb(main):002:0> YAML.dump(["1.2", "1.2.3", "1.2_3"]) => "--- \n- \"1.2\"\n- 1.2.3\n- 1.2_3\n" The first element is quoted appropriately, the second isn't because there's no ambiguity but the third should be quoted. The YAML float can have underscores, they're used as visual separators and should be ignored by the parser. So when seeing 1.2_3 the parser should read the float 1.23. Then to disambiguates the string "1.2_3" should be quoted. Practically this isn't really a problem as YAML converts on writes so YAML.dump(1.2_3) gets directly written as 1.23. However it creates some interoperability issues when "1.2_3" gest written unquoted by Syck and then read by another parser as being 1.23. The string isn't a string anymore in that case. What do you think? Thanks, Matthieu R.
on 2007-02-20 03:04
on 2007-02-20 06:13
On 2/19/07, Matthieu R. <email@example.com> wrote: > > that case. > Are you certain that 1.2_3 is a valid YAML float? http://yaml.org/type/float.html I do not believe underscores are valid in either YAML floats or YAML integers. Although they are allowed in Ruby, I believe Syck is handling your example case properly and without ambiguity. Blessings, TwP
on 2007-02-20 06:28
Hi Tim, In that page: "Any "*_*" characters in the number are ignored, allowing a readable representation of large values." So clearly they're allowed, in 1.2_3 the underscore is simply ignored and the parser should undestand 1.23. If I fancy to write my own YAML by hand and make it easily readable (which is kind of the original purpose) I could write 100_000_000.03 which would be a nice looking float. Hence the ambiguity with "1.2_3". Cheers, Matthieu
on 2007-02-20 07:13
> ambiguity with "1.2_3". But the specification is not just in english, it's also in regex form: [-+]?([0-9][0-9_]*)?\.[0-9.]*([eE][-+][0-9]+)? (base 10) |[-+]?[0-9][0-9_]*(:[0-5]?[0-9])+\.[0-9_]* (base 60) |[-+]?\.(inf|Inf|INF) # (infinity) |\.(nan|NaN|NAN) # (not a number) For a base 10 number, underscores are permitted only if they appear BEFORE the decimal point, so for 1.2_3 there is no ambiguity. Dan.
on 2007-02-20 07:25
> So clearly they're allowed, in 1.2_3 the underscore is simply > ignored and > the parser should undestand 1.23. If I fancy to write my own > YAML by hand > and make it easily readable (which is kind of the original > purpose) I could > write 100_000_000.03 which would be a nice looking float. Hence the > ambiguity with "1.2_3" Hmmmm... I just noticed that the specification (http://yaml.org/type/float.html) isn't just unclear, it's inconsistent. The examples listed include: exponentioal: 685.230_15e+03 Notwithstanding the spelling of exponential, that example is not consistent with the regular expression (which allows underscores only if they preceed the decimal point - [-+]?([0-9][0-9_]*)?\.[0-9.]*([eE][-+][0-9]+)?). Dan.
on 2007-02-20 08:16
On Tue, Feb 20, 2007 at 10:03:25AM +0900, Matthieu R. wrote: > The first element is quoted appropriately, the second isn't because there's > no ambiguity but the third should be quoted. The YAML float can have > underscores, they're used as visual separators and should be ignored by the > parser. Only in YAML 1.1. Syck only speaks YAML 1.0. Unfortunately, the types repository for 1.0 is no longer at yaml.org. See http://web.archive.org/web/20030815095109/yaml.org... for the floats which Syck should support. _why