Hi, On Wed, Jan 2, 2019 at 7:14 AM John Cowan <co...@ccil.org> wrote: > > I'm not sure where best to report these, so sending this email. >
Same as before, github issues should work. > JSON numbers have to be, in Scheme terms, either exact integers or inexact > reals excluding +inf.0, -inf.0, and +nan.0. Guile-json will blithely output > any of these three as well as 1/2, 3.4+5.6i, etc., which will not work with > other JSON parsers. > Good catch! > Symbols are currently output as JSON strings. This will be problematic if > anyone depends on it and you decide to switch to the symbol null for JSON > null, as I suggested in my previous email. I think symbols should be invalid > as JSON values. > Not sure about this one. I think it's nice to use symbols not sure if it's worth to remove support of symbols for just this case. There must be something else we can do. I'll investigate. > Symbols and numbers are allowed as object keys, converting them to strings, > which is reasonable but should be documented. > Makes sense. > If you pass anything but a string, a symbol, or a number as an object key, > you get a low-level error from string->list instead of a proper json-invalid > error. > Thanks! > The builder doesn't validate the native object first. This requires an extra > tree walk, but for example if you call (json-scm (vector 1 2 3 #u8(1 2 3))) > it will output "[1,2,3" before throwing an exception. This is not the Right > Thing: a procedure that does output should work correctly or fail cleanly > without outputting anything. > Agreed. There's should be some validation before printing anything. Again, if you could file these issues separately on github it would be fantastic! We can follow discussions, patches, etc. there. Thanks, Aleix
