Redundant Variant

[Phil Last]

I've recently used ⎕JSON for the first time in an emulator that has to work back to 14.1 when 7159⌶ & 7060⌶ were introduced.

The way our emulators work the long-winded function for older interpreters is overwritten at startup by a shorter expression or a primitive if the interpreter version is greater than or equal to that in which the enhancement was introduced.

As we now have only ⎕JSON rather than the functionality split between the two i-beams I tried it on its own and find I need the variant ('Compact' 0) for export to give me formatted JSON equivalent to 0 1(7160⌶). Fortuitously or deliberately I find that its redundancy for import is ignored rather than triggering an error so that I can code an unconditional expression that serves for both purposes.

• If it's deliberate then thank you very much for your foresight
• If it's fortuitous can please it be put on record that it should be kept thus?

[gil]

I agree, please keep this feature.

[Richard|Dyalog]

It is deliberate, but I'll raise an issue to clarify the docs, and put in QA to ensure it remains so.

The thinking behind variant is this: it takes a function and modifies it so that it has different properties - for example, ⎕JSON produces "compact" JSON when it exports APL data, but you can change that by applying ('Compact' 0) to it using variant. The derived function you get from doing that can also be modified again and again, and ⎕JSON itself is conceptually just a variant of another function buried deep in the interpreter which has had ('Compact' 1) applied to it.

So, under this model, it cannot possibly be erroneous for you to set the 'Compact' variant option on JSON import because ⎕JSON has conceptually already had ('Compact' 1) applied to it.