⎕JSON Observation

[PGilbert]

If you do the following in v18 you get the expected result:

      ⎕JSON 'hello' 1 2 3 4
["hello",1,2,3,4]

With the following line you get an 'illegal' JSON result (hello should be between quotes):

      ⎕JSON (⊂'hello') 1 2 3 4
[hello,1,2,3,4]

The following line will create an error:

      ⎕JSON 'hello' (⊂1 2 3 4)
DOMAIN ERROR: JSON export: item "[2]" of the right argument cannot be converted (⎕IO=1)
      ⎕JSON'hello'(⊂1 2 3 4)
      ∧

Personally I would prefer a DOMAIN ERROR instead of an illegal JSON so that the error could stay in APL. Otherwise, you send some JSON variable to Chromium thinking that it is correct and Chromium is bugging on that variable.

So to make sure that the JSON variable is correct you have to parse it before sending it to Chromium to verify if it is valid:

      ⎕JSON ⎕JSON (⊂'hello') 1 2 3 4
DOMAIN ERROR: JSON import: invalid character at offset 2 (⎕IO=1)
      ⎕JSON ⎕JSON (⊂'hello') 1 2 3 4
      ∧

I can live with this behavior but in case this is not the correct behavior let us know.

Regards,

Pierre Gilbert

[Morten|Dyalog]

Hi Pierre!

This is an intentional feature: we take advantage of the fact that a scalar enclosed string has no valid JSON representation to allow you to inject things that have no corresponding APL representation into the data stream.

For example, this allows you to get true, false or null into the output, and the F1 help example also shows how to inject JavaScript expressions into the result. This is very useful when generating data for web clients.

I suppose we could consider a variant option to disallow this.

[PGilbert]

Thanks for the explanation, Morten. I was under the impression that Dyalog wanted that the ⎕JSON generate always 'valid' JSON. But if there is a logic in this behavior then everything is fine. I can see that for javascript keywords it is helpful and it is generating valid JSON:

      ⎕JSON (⊂'true') 1 2 3 4
[true,1,2,3,4]

⎕JSON ⎕JSON (⊂'true') 1 2 3 4
  true   1 2 3 4