4 ms·

(As someone strongly against adding new features to languages,) I've never understood where there would be any need for anything more complicated than list conc

(As someone strongly against adding new features to languages,) I've never understood where there would be any need for anything more complicated than list concatenation when assembling bits. In some language with list notation, (++ being concatenation of two lists) you could do something like this: [0] ++ sendSeq ++ recvSeq ++ [poll] say sendSeq was one bit but we still wanted it to take 3 bits: [0] ++ pad 3 sendSeq ++ poll ++ recvSeq given some "pad" function defined in a library The only reason it's "hard" in C is because the operations are induced from what the machine can do efficiently and without "a sufficiently smart compiler".

macintux 5y ago
The bit syntax in Erlang is for deconstruction and assignment (pattern matching), not just assembling. The entire language is built around pattern matching to the point where it simply wouldn't exist otherwise, and I assume binary protocol handling was a core requirement when the language was designed since it was created for telecom switches.
Jtsummers 5y ago
https://erlang.org/doc/programming_examples/bit_syntax.html https://erlang.org/doc/programming_examples/bit_syntax.html > say sendSeq was one bit but we still wanted it to take 3 bits: > [0] ++ pad 3 sendSeq ++ poll ++ recvSeq In Erlang you could do this to get something padded (or truncated) to the correct size: << 2:3 >> ;; corresponds to the 3 bits <<010>> So you can do something like this to ensure the precise bit size of each field: << 0:1, SendSeq:3, Poll:3, RecvSeq:3>>
- voidnullnil 5y ago
  Yaeh, my point was that it is trivial to define a pad function and call it instead of needing some syntax like Erlang. But now I see there is deconstruction too, which is more arguably useful to take the time to add syntax for.
spc476 5y ago
C has the concept of bit fields, and this could be specified as: struct build_info_control { unsigned char : 1; unsigned char SendSeq : 3; unsigned char Poll : 1; unsigned char RecvSeq : 3; }; struct build_info_control control; control.SendSeq = sendSeq; control.Poll = true; control.RecvSeq = recvSeq; The downside of bit fields is that they are implementation specific---you'll have to check the compiler documentation to see if the bits are specified "most significant bit to least significant bit" or "least significant bit to most significant bit" (if that is indeed, important to the problem).

macintux 5y ago

The bit syntax in Erlang is for deconstruction and assignment (pattern matching), not just assembling. The entire language is built around pattern matching to the point where it simply wouldn't exist otherwise, and I assume binary protocol handling was a core requirement when the language was designed since it was created for telecom switches.

Jtsummers 5y ago

https://erlang.org/doc/programming_examples/bit_syntax.html https://erlang.org/doc/programming_examples/bit_syntax.html > say sendSeq was one bit but we still wanted it to take 3 bits: > [0] ++ pad 3 sendSeq ++ poll ++ recvSeq In Erlang you could do this to get something padded (or truncated) to the correct size: << 2:3 >> ;; corresponds to the 3 bits <<010>> So you can do something like this to ensure the precise bit size of each field: << 0:1, SendSeq:3, Poll:3, RecvSeq:3>>

voidnullnil 5y ago
Yaeh, my point was that it is trivial to define a pad function and call it instead of needing some syntax like Erlang. But now I see there is deconstruction too, which is more arguably useful to take the time to add syntax for.

spc476 5y ago

C has the concept of bit fields, and this could be specified as: struct build_info_control { unsigned char : 1; unsigned char SendSeq : 3; unsigned char Poll : 1; unsigned char RecvSeq : 3; }; struct build_info_control control; control.SendSeq = sendSeq; control.Poll = true; control.RecvSeq = recvSeq; The downside of bit fields is that they are implementation specific---you'll have to check the compiler documentation to see if the bits are specified "most significant bit to least significant bit" or "least significant bit to most significant bit" (if that is indeed, important to the problem).