JSON decoding

P T Withington ptw at pobox.com
Fri Nov 3 04:32:06 PST 2006


I think we have this upside down.  We're worried about the user  
creating an invalid JSON string.  Why?  Because they could break the  
reader?  Doesn't the reader have to protect itself?  (Perhaps the  
lure of eval as a reader has confused us.)

It seems more important to tell the user:  'You tried to create a  
JSON representation of something, but it can't be represented in a  
way that parseJSON can meaningfully reconstruct it".

 From an historical point of view, perhaps we are trying to do too  
much with JSON.

JSON reminds me of Lisp's print/read, which eventually evolved a flag  
[*print-readably*](http://www.lisp.org/HyperSpec/Body/var_stprint- 
readablyst.html#STprint-readablyST).  If true, you will get an error  
if you try to print an object that cannot be represented in a way  
that read can parse and construct a 'similar' object.  Print/read  
relies, as does JSON, on the implicit type-encoding of the language  
literals.

toJSON seems like 'half a loaf'.  It lets me encode an arbitrary  
object, but without a corresponding fromJSON, what use is it?

Compare that to dump/load, which is supported by [make-load-form] 
(http://www.lisp.org/HyperSpec/Body/stagenfun_make-load-form.html),  
which allows you to write arbitrary expressions for reconstructing  
objects.  Dangerous for reading arbitrary data.  Or compare Java  
serialization, which has a more restricted mechanism for  
reconstructing arbitrary objects.  Less dangerous.  Pretty  
heavyweight.  Maybe not what you are looking for in a lightweight  
scripting language.





More information about the Es4-discuss mailing list