Hacker News Reader

Comment by codesections | Hacker News Reader

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

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). 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`)

(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".

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.

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>>

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.

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).

Reply on news.ycombinator.com