[krapp]

I suppose my point was that you don't have to specify types for maps and sets at all (which I didn't do in my example,) the existing syntax already does that. [] is already a set, {} is already a map. Type hints would just be used for the values.

Sending type definitions seems like a good idea. Although at that point it might as well not even be called any kind of JSON.

[kybernetikos]

I don't agree that you don't have to specify types for maps and sets. For example

    {true: "yes", false: "no"}

Is not valid JSON, but

    Map [[true, "yes"], [false, "no"]]

should be valid 'NuJSON'. Maps and Sets are semantically different to Objects and Arrays, and they are Javascript standard objects that should ideally be supported by the default serialisation. The other alternative of course is to force the deserialisation code to fix them up afterwards, but that is painful.

I want to be able to stringify records with Sets, Maps, Arrays and Objects in, and have that work, even if they have behavior not supported by objects and arrays, and I don't think the user should have to fix up the output after parsing of JSON containing standard javascript objects.