A jsexpr is one of:The nice thing about this representation is that it's easier to quote and quasiquote. The down-sides are that array manipulation is a little less convenient, and table lookup is slower.
- 'null
- boolean
- string
- integer
- inexact-real
- (vectorof jsexpr)
- (listof (cons symbol jsexpr))
Another alternative is:
A jsexpr is one of:The nice thing about this is that both arrays and tables are conveniently represented as lists. But it's a little uglier for representing null, which is necessary to avoid ambiguity between the JSON strings { "null" : [] } and [[null]]. Note that it's also a little more subtle to distinguish between arrays and tables.
- #:null
- boolean
- string
- integer
- inexact-real
- (listof jsexpr)
- (listof (cons symbol jsexpr))
Other possible unambiguous representations of null include #\null, #"null", or #&0. Yech.
If you have any opinions, feel free to comment here or email me privately.
Update: Whoops, can't have them both be lists, because of the ambiguity between the empty object and empty array.
4 comments:
I use json.plt, mainly to serialise hashes for javascript consumption. I think the second alternative seems more flexible by not requiring vectors in order to produce json arrays. I guess the convenience is determined by whether the client naturally uses vectors or lists. I guess both could be accommodated in the cond statement of 'write' in json.ss, but what about 'read'? If you need to make a determination one way or the other, I personally would opt in favour of lists.
As for null representation, I suspect this may purely come down to a matter of taste. Personally, I find either 'null or #\null the least offensive, aesthetically.
Be bold. Cower not before the false portent of backwards compatibility. When using third-party libraries, good practice mandates coding against specific versions of the library anyway. So go ahead and make the change--your users will either adopt it or continue with what already works for them.
I agree with Simon that, on average, it's more convenient to represent arrays as lists.
This means you'd need an alternative representation for objects. Hash tables are the current choice, but as you mentioned to me the other day they are less convenient for quoting because you can't do:
'#hash((,unquoted-expr . value))
Just thinking out loud... How about wrapping hashes in an alist inside a prefab struct?
(define-struct json-object (values) #:prefab)
Then you could do:
'#s(json-object ((,unquoted-expr . value)))
It's quotable and it means you can use lists to represent arrays, but it certainly isn't as neat as using a primitive Scheme type.
The {{{#\nul}}} character for {{{null}}} ! Brilliant hack!
Engaging with cheap custom essay writing services can be a practical approach for students looking for affordable and well-crafted essays. Balancing cost and quality ensures that you receive value for your investment in academic support.
Post a Comment