[Feature Request] Support for Compound Operators in ROS Scripting

RouterOS Scripting
1

1. :bullseye: Introduction and Objective

This proposal aims to enhance the efficiency and readability of the RouterOS Scripting language (RSC). We propose the addition of support for common Compound Assignment Operators, such as += and -=, which are standard features in almost all modern programming languages.

2. :confounded_face: Current Problem

In the current versions of RouterOS Scripting, modifying a variable's value based on its existing value requires explicitly typing the variable's name twice. This leads to verbose code, reduces readability, and increases the potential for simple typographical errors, especially in complex scripts.

Current Format (Verbose):

:set counter ($counter + 1)
:set totalBytes ($totalBytes + $indexBytes)

This syntax is non-concise and hinders efficient script maintenance.

3. :sparkles: Proposed Solution (Compound Operators)

We request support for the standard Compound Assignment Operators (+=, -=, *=, /=, %=) to simplify integer-based arithmetic in RouterOS scripting. This feature allows concise modification of a variable's value, replacing the verbose format (e.g., :set x ($x + 1)) with the efficient syntax (e.g., :set x += 1). Implementing this industry-standard feature will significantly improve code readability and accelerate scripting efficiency for all users.

4. :white_check_mark: Expected Benefits

  1. Improved Readability: Makes scripts clearer, cleaner, and easier to understand upon review.
  2. Code Conciseness: Shortens scripts, which is beneficial for overall code management.
  3. Faster Scripting: Enables engineers and developers to write scripts more quickly and with fewer chances of basic syntax errors.
  4. Industry Alignment: Brings the RouterOS scripting language closer to industry best practices found in languages like C, Python, and JavaScript.

5. :handshake: Conclusion

The inclusion of Compound Assignment Operators is a minor technical change with a significant positive impact on the User Experience (UX) for developers and administrators who rely heavily on RouterOS scripts. We hope this proposal will be considered for adoption in future system updates.

Sincerely,

2

No! The = token in RouterOS is not used for variable assignment. += would be completely out of place as an increment operator. Don't try to import foreign syntax like that. Not all languages have to be derived from C.

Assignment is performed in ROS script with :set. To be consistent, you should suggest the introduction of the :inc and :dec commands instead.

:inc counter
:inc totalBytes $indexBytes
3

To be fair, in (good ol') batch (still scripting, and NOT programming), this is doable, i.e.:
C:>set /a test=10
10
C:>set /a test+=10
20

And I don't think it is derived from C.

4

The

set variable = expression

syntax is from C Shell (which predates batch files) as you can see from this summary: Assignment (computer science) - Wikipedia

RouterOS is command oriented, and the assignment is a command. And I think it's probably influenced by Tcl, which use the same assignment syntax. Look at this and see if anything is familiar, even the use of [...] to evaluate sub-expression: Tcl - Wikipedia

1 Like
5

RouterOS takes influences from many paradigms. But one it does not borrow is the = for variable assignment — why the += is inconstant. Now bitwise operators do borrow from C, so that should not be disqualifying...

One could argue the ++ and -- might be nice-to-haves, like:
:set counter++

But this ignores several larger themes...

  1. Specifically that RouterOS is a configuration language and more "functional" than "procedural" language. In functional languages "global" (or any) variables are anti-pattern.
  2. And importantly RouterOS variables have "bigger" problems, before getting a ++/--, there are neither persistent (available across reboots), system-wide variables (global is, generally, scoped to process/user), and "secure" (and persistent) variables (for keys/passwords so that they do not appear in plain-text in script and printed in log).
1 Like