[kybernetikos]

I think the main difference between my suggestion and yours is that mine has more brackets. I think type hinting and 'constructors' are basically the same thing, but I like the types to be extensible, so even in your version, I'd make the type hints things that could be provided into the NuJSON.parse function.

Obviously, in your version my approach would be

    sounds: Map {
        cow: "moo",
        fox: null
    },
    possibilities: Set ["she loves me", "she loves me not", 42]

I suppose that the idea could be that type hints are entirely ignoreable, and if you strip them the file just becomes normal JSON?

[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.