Consider JSON.parse

[FUDCo]

I concur with the proposal that records and tuples serialize to JSON via JSON.stringify as object and array. It strikes me that there may be value in providing support for going in the other direction, to somehow parameterize JSON.parse to yield a structure consisting of records and tuples. Obviously, this could be implemented in user land with the existing JSON.parse and some tree crawling and type conversion logic, but supporting it directly would be a good deal more efficient. Since many use cases for parsing JSON (actually, I'd speculate a majority of them) neither need nor want the parsed result to be mutable this could be a win.

[rricard]

Agreed, the question being where would we add the option to parse into Record/Tuple instead of Objects/Arrays. Parameterizing JSON.parse might be tricky as it already takes a second reviver function argument.

[papb]

What if a new JSON.parseAsImmutable was provided?

[littledan]

Let's add this function--everyone is asking for it, and it seems useful to me too. As a starting point, I would suggest Record.parseJSON (even though it doesn't always return a record), and then we can bikeshed on the naming from there.

[rricard]

Agreed, putting it on Record is actually the best option so far

[dcporter]

(Isn't [] valid JSON though?)

[rricard]

Well, yes, but it wouldn't be the end of the world to have this Record.parseJSON be able to return a Tuple. The main advantage of that approach is to avoid extending an existing namespace such as JSON...

[dcporter]

The main advantage of that approach is to avoid extending an existing namespace such as JSON...

Thanks Robin. What's the benefit of this? I would expect JSON parsers to live on JSON.

[rricard]

Of course, the thing is we have to guarantee compatibility with existing websites. However unlikely it is, there might be an instance of library that adds methods to JSON or tweak JSON.parse.

That being said, research and measurements can be done to ensure websites do not do that. Adding to a new namespace however, clears us of doing any of that work. As of now, I'll probably put that on the table for the committee to advise. Maybe it is a non-problem.

[dcporter]

As of now, I'll probably put that on the table for the committee to advise. Maybe it is a non-problem.

Sounds great. My hope and expectation is that it's a non-problem, in which case using the JSON namespace for JSON stuff seems to me like a big win. =)

[littledan]

I wouldn't worry too much about the web compatibility of extending the JSON namespace (at least not any more than I would worry about the web compatibility of adding the Record global...). We just need to reach a name that we can all agree on. Do you have an idea for what the method should be called?

[papb]

What if a new JSON.parseAsImmutable was provided?

This was my first idea. Perhaps JSON.parseImmutable could work as well.

[Olian04]

Wouldn't it make more sense to parse data as the most tolerant datatype of the two; then create the more strict datatype using the tolerant one.

Record.from(JSON.parse(string))

That way we wouldn't have to pollute the JSON namespace.

[rricard]

@Olian04 you would generate an intermediary object representation in memory, by doing this you would cancel the advantages of such parser.