Filed all issues. On Wed, Jan 2, 2019 at 6:44 PM Aleix Conchillo Flaqué <aconchi...@gmail.com> wrote:
> 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 >
