Support Arithmetic Operations

[solara404]

Fix: #276

The set() function has been extended to support arithmetic operations.
The existing behavior remains unchanged to preserve backward compatibility

Previously:
set (variable) (value)

New:
set (variable) (value) [operation] [value]
value is computed when the= symbol is used. Variables with numeric values can be used. Numbers, variables, and operators may be separated with spaces.

For example, set x =10*2+1 is equivalent to set x = 10 * 2 + 1.

Supported operators and symbols: +, -, *, /, %, (, )

Example:
set x 10
set y x + 5 // y = 15
set z y * x // z = 150

set x 10            // equal to "set x = 10" for numeric values
set y = x + 1       // y = 11
set z = 2             
set z = x + z * 2   // z = 14
set y = x y         // y = 110 
set x = 2x          // x = 20

When = is used, variables are resolved.

set xyz 1
set abc xyz       // abc = "xyz"
set mno = xyz     // mno = 1

[aaumar25]

It is one way to do that. Since we are going to support arithmetic operation, why do not we try to support it more naturally? How about this use case

set x = 10
set x=10
set y = x * 2 + 10
set y=x*2 + 10

Lets commit into supporting it, but limit the supported operators to the one you mentioned. Also be careful with invalid operation like dividing by zero.

[solara404]

I was thinking of something like this. However, I wanted to use the existing parseAndRun() function.

[solara404]

@aaumar25 the more natural way has been implemented. It can now be used with and without adding space.

[solara404]

@aaumar25 Should the PR title be marked as breaking?
I would also change the commit message of the following commit:

feature: add 'rest' functionality to parseAndRun()
to:
feat!: add 'rest' functionality to parseAndRun()

And additionally, adding information to the PR description.

BREAKING CHANGE: A additional rest parameter has been added. Functions that rely on raw argument indexes beyond the final rest parameter will need to update their logic.

[aaumar25]

Good approach regarding the calculation structure. I think the output of calc should be floating point instead of integer. What happen if want the following operation to change next carrier target position with car_pos + 0.33?

[aaumar25]

@aaumar25 Should the PR title be marked as breaking?

I do not think it is breaking anything, it just added one field with default value, so existing parameters does not need to explicitly assign rest field.

However, I am thinking about catching the rest field in the compile time, so that we can return compile error instead of checking it in runtime.

[aaumar25]

Just squash and merge