Discussion on supporting mathematical operations in values

[XGHeaven]

demo follow

{
    num1: 1*2*3,
    num2: 1*2%3,
    num3: 3 / 2,
    num4: 3 << 1,
    num5: 2**3
}

the result is

{
    num1: 6,
    num2: 2,
    num3: 1.5
    num4: 6,
    num5: 8
}

the follow operator should be supported:

• *
• /
• +
• -
• %

others I hope also:

• **
• >>
• <<
• <<<
• >>>
• //? divisible operator or ///

What think about yours??

[jordanbtucker]

At first I was opposed to this, but I've written plenty of code like 24*60*60*1000 for the number of milliseconds in a day.

What's better?

{
  ms: 86400000, // one day
}

or

{
  ms: 24*60*60*1000, // one day
}

The first example appears like it doesn't require the parser to do any math, but the parser already has to do math to parse the number as base 10. The second example is easier to modify if you want to change it to e.g. 12 hours or 3 days.

[paulcscharf]

If this was done (and I feel divided about it too.. yet it would be really cool to have), should it also support parenthesis?

I could imagine someone wanting to encode some sort of offset like (base+increment)*stride for example. (And I am sure there are more good use cases.)

[piranna]

I could imagine someone wanting to encode some sort of offset like (base+increment)*stride for example. (And I am sure there are more good use cases.)

This would need (or lead) to have support for constants or at least get that variables from the context... This will break compatibility with json, but would be a nice feature too. Maybe in a new spec with regex too?

[jordanbtucker]

I think @amulware, correct me if I'm wrong, was just using variables to represent numeric literals. For example, you could have:

{ offset: (10 + 3) * 2 }

but not the literal string:

{ offset: (base + increment) * stride }

But it is an interesting concept to declare variables in a JSON5 file. Maybe we should start a new discussion on that.

Also, see #91 for a discussion on why regular expressions have not been included in JSON5.

[paulcscharf]

Yes, I indeed only meant using literals, like @jordanbtucker says.

Using variables like that would make things a lot more complicated and would have to be discussed in a lot of detail I imagine.

[XGHeaven]

@amulware you meaning is like

{ offset: (base + increment) * stride }

not

{ offset: (10 + 3) * 2 }

[paulcscharf]

You confuse me. :D

I was only asking about adding parenthesis to the list of supported operators, so I only care about:

{ offset: (10 + 3) * 2 }

The other things is a much bigger feature that needs to be designed very carefully, if it is a good idea at all.

[piranna]

I've open an issue for discussion about the variables at #112.

[aseemk]

I too have been pretty hesitant about this feature request, because it's hard to know if it's gone just a bit too far beyond the line of "minimal but useful"... but I also agree with @jordanbtucker that I too have written 60 * 24 * ... multiple times for (non-JSON) config-ish constant values.

I'd be okay with adding basic math operators. I would discourage adding **, etc., as those aren't standard ES5 either. (But I do appreciate them in CoffeeScript.)

[piranna]

I think the limit will be when people want to use functions or Math.sqrt() or import modules ;-)

[XGHeaven]

@aseemk Yes, I agree with minimal but useful. So I only add + - * / feather in my PR. It's enough.

[aseemk]

@piranna: I totally agree that functions are beyond the line. A core tenet of JSON(5) is "it's just data", not executable code.

@XGHeaven: agreed, thank you.

Even with these basic operators, though, it does e.g. make supporting JSON5 in other languages harder. E.g. what is 5 / 0? If we're to be consistent with ES5, it's Infinity. But in most languages, that'd be a runtime error. Or possibly an undefined-ish value.

[XGHeaven]

You said "It's just data". So I believe 5 / 0, no one could write it... 😄 useless data...

[piranna]

@piranna: I totally agree that functions are beyond the line. A core tenet of JSON(5) is "it's just data", not executable code.

I consider RegExp data, too... ;-) They are the same as function declarations as far as they are not executed, but function declaration would be beyond the line too not only because they are language specific but also could be dangerous if executed (RegExp are not dangerous in that way).

Even with these basic operators, though, it does e.g. make supporting JSON5 in other languages harder. E.g. what is 5 / 0? If we're to be consistent with ES5, it's Infinity. But in most languages, that'd be a runtime error. Or possibly an undefined-ish value.

Infinity is a valid float value in all languajes, including C/C++...

[jordanbtucker]

I'm glad we're getting some great discussions around this. That's what I was hoping for 😄

@aseemk

I'd be okay with adding basic math operators. I would discourage adding **, etc., as those aren't standard ES5 either. (But I do appreciate them in CoffeeScript.)

I totally agree here. Let's keep things ES5 compliant.

@aseemk

Even with these basic operators, though, it does e.g. make supporting JSON5 in other languages harder. E.g. what is 5 / 0? If we're to be consistent with ES5, it's Infinity. But in most languages, that'd be a runtime error. Or possibly an undefined-ish value.

I'd alter that statement by saying that 5 / 0 is an error in most languages if they're treated as integers. ES5 doesn't have integers (all numbers are IEEE 754 floating point values) so this returns Infinity. If the numbers are treated as floating points, then most languages would return some form of IEEE 754 Infinity. (Python and Go are exceptions, however. Python always throws a ZeroDivisionError. The Go spec says it's implementation specific, but the official Playground throws a division by zero error. There are likely other exceptions, too).

@piranna

I consider RegExp data, too... ;-) They are the same as function declarations as far as they are not executed, but function declaration would be beyond the line too not only because they are language specific but also could be dangerous if executed (RegExp are not dangerous in that way).

Oh no. Now the RegExp discussion is bleeding into this one. 😉 I do see the parallels, though.

@piranna

Infinity is a valid float value in all languajes, including C/C++

Most languages have a way to check for Infinity, but not all languages have a way of actually representing that value (e.g. a constant that represents Infinity or a function that returns Infinity). PHP 4.0 is an example of this.

[aseemk]

Great discussion indeed! Very good food for thought. =)

I'll keep chewing on it...

[piranna]

Even with these basic operators, though, it does e.g. make supporting JSON5 in other languages harder. E.g. what is 5 / 0? If we're to be consistent with ES5, it's Infinity. But in most languages, that'd be a runtime error. Or possibly an undefined-ish value.
I'd alter that statement by saying that 5 / 0 is an error in most languages if they're treated as integers. ES5 doesn't have integers (all numbers are IEEE 754 floating point values) so this returns Infinity. If the numbers are treated as floating points, then most languages would return some form of IEEE 754 Infinity. (Python and Go are exceptions, however. Python always throws a ZeroDivisionError. The Go spec says it's implementation specific, but the official Playground throws a division by zero error. There are likely other exceptions, too).

This operations will not be executed on runtime but when parsed, so there's no problem the implementation wrap the operations on a try-catch block to capture these exceptions and set the value to infinite "by hand". Python support both Infinite and NaN, so...

Oh no. Now the RegExp discussion is bleeding into this one. I do see the parallels, though.

Lol :-P Yes, there are parallels because it depends on the concepts of "what is data" and "what is executable code". After parsing we would get respectively a number or a RegExp object that both are not executables by themselves (a RegExp is a description that can be used to find some data, the same way a number can be used as an index on an array), so I would accept both. I would not accept functions because if they get parsed they are executables "as is", and there's almost no way to sanitize them and know they are secure (a RegExp could be bad written, but it's not a security thread or could erase data by itself...).

@piranna

Infinity is a valid float value in all languajes, including C/C++
Most languages have a way to check for Infinity, but not all languages have a way of actually representing that value (e.g. a constant that represents Infinity or a function that returns Infinity). PHP 4.0 is an example of this.

PHP sucks, but not so much... ;-)

[jordanbtucker]

@piranna

This operations will not be executed on runtime but when parsed, so there's no problem the implementation wrap the operations on a try-catch block to capture these exceptions and set the value to infinite "by hand". Python support both Infinite and NaN, so...

No one was saying that it can't be done in those languages. @aseemk's point was that more work would need to be done in those languages to support JSON5 with math features. In Python, you can't just parse a / and perform division on the operands. Like you said, you have to check whether the divisor is a zero and return float("inf").

The more complex you make a specification, the more work that needs to be done to implement it, and the less it actually gets implemented.

PHP sucks, but not so much... ;-)

I know PHP supports NaN and Infinity at this point in time. I was referring specifically to PHP 4.0. And regardless of whether PHP sucks, it's still an extremely popular platform for web applications.

[jordanbtucker]

@piranna

Lol :-P Yes, there are parallels because it depends on the concepts of "what is data" and "what is executable code". After parsing we would get respectively a number or a RegExp object that both are not executables by themselves (a RegExp is a description that can be used to find some data, the same way a number can be used as an index on an array), so I would accept both. I would not accept functions because if they get parsed they are executables "as is", and there's almost no way to sanitize them and know they are secure (a RegExp could be bad written, but it's not a security thread or could erase data by itself...).

Supporting functions is not just about security. You would have to expect the JSON5 parser be able to parse functions and implementations to be able to represent those functions on their native platforms. If someone wants to implement functions in JSON or JSON5, they might as well write a transpiler for ES5 into every other programming language.

Regarding regular expressions, I wrote a little more about the subject.

[piranna]

Supporting functions is not just about security. You would have to expect the JSON5 parser be able to parse functions and implementations to be able to represent those functions on their native platforms. If someone wants to implement functions in JSON or JSON5, they might as well write a transpiler for ES5 into every other programming language.

And also, adding functions support would deviates from being a data format to became a programming languaje...

Regarding regular expressions, I wrote a little more about the subject.

Your last solution (map RegExp.toJson() to RegExp.toString()) so they got embebed inside strings is just what I'm doing in another project processing them with another data types and it works like a charm... :-D Maybe we could add and process the RegExp in the same way, storing them as strings :-)

[jordanbtucker]

@piranna

Your last solution (map RegExp.toJson() to RegExp.toString()) so they got embebed inside strings is just what I'm doing in another project processing them with another data types and it works like a charm... :-D Maybe we could add and process the RegExp in the same way, storing them as strings :-)

I'm open for discussions on serializing RegExps as strings. In fact, I've renamed and re-opened the issue. Let's keep further discussions there. Thanks.

[piranna]

I'm open for discussions on serializing RegExps as strings. In fact, I've renamed and re-opened the issue. Let's keep further discussions there. Thanks.

👍 let's keep the issues focused :-)

[jordanbtucker]

Hey, everyone. I'm going to close this issue because it is incompatible with the official specification. If you would like to continue this discussion, please open an issue on the official specification repository. Please see the new issues template for more information. Thanks.