[MNScript RFC] Better Bitwise

Status
Not open for further replies.
AnthonyFuller

AnthonyFuller

Active member
Aug 26, 2023
21
2
21

Summary​

Add new bitwise operators: <<, >>, and ~. And a Bit library, for all the extra functions e.g. XOR.

Motivation​

Currently, MNScript supports the bitwise AND and OR operations, those being & and | respectively. This support should be extended to other operations to allow for more creative use of integers, and compact storage of numbers and flags.

You can get really creative with storing data in a single 32-bit number, there's one enterprise solution on the market that stores up to 8 things in a single 32-bit number.

Currently, there is no way to do any bit shifts, bitwise NOT, or bitwise XOR natively in MNScript.

Some other bit library functions from gLua would be good for specific usecases, for example, rol and ror can be used in ciphers.

Design​

New operators:
  • Left shift: << - Implemented using gLua's bit.lshift
  • Right shift: >> - Implemented using gLua's bit.rshift
  • Bitwise NOT: ~ - Implemented using gLua's bit.bnot

New "Bit" library (these are all implemented by using their respective functions in the gLua bit library):
  • Bit.arshift<number>(number value, number shiftCount)
  • Bit.bswap<number>(number value)
  • Bit.xor<number>(number value, number otherValue)
  • Bit.rol<number>(number value, number shiftCount)
  • Bit.ror<number>(number value, number shiftCount)
bit.tobit and bit.tohex have been excluded as I do not see many uses for those in MNScript other than "nice to haves", this would be up to the implementer.

Unfortunately, as ^ is used for exponents, it cannot be used for XOR.

Drawbacks​

The addition of this new operator would (most likely) add some complexity to the compiler and VM (and may even need a new compiler version). These could possibly be viewed as a drawback.

Another drawback of this could be user confusion regarding << and >> being confused with < and > respectively (and possibly confusion surrounding how to use ~). A solution for this would be to forego implementation of these new operators and instead implement them through the proposed library.

Alternatives​

Alternatives to this approach include excluding these functions completely or implementing them all through the proposed Bit library (like gLua). This approach (adding new operators) shares semantics and syntax with other languages like C++.

Edits​

2023-08-29 - Added drawback regarding user confusion.
 
Last edited:
Upvote 2 Downvote
Hydro

Hydro

Civil Gamers Expert
One Year Club Two Year Club Three Year Club Community Engager
Dec 19, 2020
216
125
71
Just my 20 cents, I support `<<`, `>>`, `|` and `&` as bitwise operators. I'd be tempted to defer to a library for all other bitwise operations not covered by those operators. I would also include those as part of said library if I were implementing this myself.

Edit: On second thoughts `&` and `|` may not be so good, purely for the fact it may cause confusion for inexperienced mnscripters. Bit of thought maybe required?
 
AnthonyFuller

AnthonyFuller

Active member
Aug 26, 2023
21
2
21
Remmy said:
We prefer to use libraries for bitwise, since different programming languages use different symbols as operators.
Click to expand...
This is a fair point, although the shift ones are pretty standardised.

Hydro said:
Edit: On second thoughts `&` and `|` may not be so good, purely for the fact it may cause confusion for inexperienced mnscripters. Bit of thought maybe required?
Click to expand...
& and | were not included in this RFC as they already exist, and I have seen confusion between these symbols in code samples people have requested help with.

I have edited my original post adding in a drawback about the shift operators possibly causing confusion with the less than and greater than operators.
 
Last edited:
Status
Not open for further replies.
Top Bottom