You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Operators that treat integers as bit sequences could definitely have a place in today's 007, if it weren't for the fact that they aren't so much on the hot path for the inner workings of a compiler tool chain.
My thinking lately though is that they have a place both (a) as opcodes in an eventual runtime/VM, and (b) as user-exposed operators through a language-extending module or two.
Why? Basically three reasons:
While they aren't vital for the inner workings of a compiler tool chain, they do tend to be vital on the periphery. Reading and writing from files means dealing with bytes and encoding/decoding. Something like a checksum algorithm will want to take a byte view on things.
Ever since I wrote examples/nim-addition.007, I've felt that it's quite silly that we don't have anything neat and low-level to use for bitwise exclusive or. Even if the base language doesn't expose an operator for it, there should be a bytecode opcode that we can just dig down to and use. (It's a rare case of being stuck at too high an abstraction level!)
There are a fair amount of optimizations that generate opcodes doing bitwise arithmetic.
There are two possible syntaxes to choose from for all the bitwise operators:
name
C-family style
Perl 6 style
bitwise negation
~
prefix:<+^>
bitwise and
&
infix:<+&>
bitwise or
|
infix:<+|>
bitwise xor
^
infix:<+^>
left shift
<<
infix:«+<»
right shift
>>
infix:«+>»
In order to make this issue actionable, I'd consider it closed when both of those syntaxes are available through language-extending modules. The runtime/VM opcodes can wait until we have a dedicated runtime.
The text was updated successfully, but these errors were encountered:
Operators that treat integers as bit sequences could definitely have a place in today's 007, if it weren't for the fact that they aren't so much on the hot path for the inner workings of a compiler tool chain.
My thinking lately though is that they have a place both (a) as opcodes in an eventual runtime/VM, and (b) as user-exposed operators through a language-extending module or two.
Why? Basically three reasons:
While they aren't vital for the inner workings of a compiler tool chain, they do tend to be vital on the periphery. Reading and writing from files means dealing with bytes and encoding/decoding. Something like a checksum algorithm will want to take a byte view on things.
Ever since I wrote
examples/nim-addition.007
, I've felt that it's quite silly that we don't have anything neat and low-level to use for bitwise exclusive or. Even if the base language doesn't expose an operator for it, there should be a bytecode opcode that we can just dig down to and use. (It's a rare case of being stuck at too high an abstraction level!)There are a fair amount of optimizations that generate opcodes doing bitwise arithmetic.
There are two possible syntaxes to choose from for all the bitwise operators:
~
prefix:<+^>
&
infix:<+&>
|
infix:<+|>
^
infix:<+^>
<<
infix:«+<»
>>
infix:«+>»
In order to make this issue actionable, I'd consider it closed when both of those syntaxes are available through language-extending modules. The runtime/VM opcodes can wait until we have a dedicated runtime.
The text was updated successfully, but these errors were encountered: