4 ms·

Out of curiosity, what makes the Erlang syntax so good?

the_only_law 5y ago
It's super easy to construct binaries and bitstrings even when you need to work with award sizes or set bits at weird positions and IMO looks a lot cleaner than a lot of shifting and boolean operators. For example constructing a 8-bit LAPB Information transfer control field might look like: build_info_control(SendSeq, RecvSeq, Poll) -> <<0:1, SendSeq/bitstring, Poll/bitstring, RecvSeq/bitstring>>. Where the `SendSeq` and `RecvSeq` are 3-bit sequence numbers... say one of them is `<<2:3>>` (0b010) and Poll is a single bit (you can see the format here: https://imgur.com/a/9bVBM0W https://imgur.com/a/9bVBM0W). This field would then be stuck into a binary representing the entire frame. This could probably be made a littler simpler, though, as I'm still rather new to Erlang. Note you also do get bit shift operators for cases when they’re an appropriate solution (`bsl` and `bsr`)
- voidnullnil 5y ago
  (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).

It's super easy to construct binaries and bitstrings even when you need to work with award sizes or set bits at weird positions and IMO looks a lot cleaner than a lot of shifting and boolean operators. For example constructing a 8-bit LAPB Information transfer control field might look like: build_info_control(SendSeq, RecvSeq, Poll) -> <<0:1, SendSeq/bitstring, Poll/bitstring, RecvSeq/bitstring>>. Where the `SendSeq` and `RecvSeq` are 3-bit sequence numbers... say one of them is `<<2:3>>` (0b010) and Poll is a single bit (you can see the format here: https://imgur.com/a/9bVBM0W https://imgur.com/a/9bVBM0W). This field would then be stuck into a binary representing the entire frame. This could probably be made a littler simpler, though, as I'm still rather new to Erlang. Note you also do get bit shift operators for cases when they’re an appropriate solution (`bsl` and `bsr`)

voidnullnil 5y ago
(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).