As to the originally referenced article, ++ isn’t asymmetric in the way it was shown but rather it’s a function that would be written like this in elixir:
def ++(left, right), do: append(:lists.reverse(left), right, [])
def shift_cells([], acc), do: acc
def shift_cells([e|r], acc), do: [e, acc]
Which is precisely what it is defined to do. Lists on the beam in erlang and elixir are not typed lists, they are not full “proper” Cons lists, you can potentially make lists in the first Cons element, the second, zig zag every which way, etc… The ending element isn’t special, it doesn’t need to be a list. Now sure ++ would not make much sense in a statically typed language, but erlang/elixir are not statically typed languages. It’s not an asymmetry as it is not a ‘prepend’ operator, it is more of a ‘shift cells over’ operator.
As for this article, looks good. ^.^
You really should put what OTP version you were working with in Erlang as a lot of error responses for BIF’s have changed in recent versions (more information in the exceptions! ^.^).
I wouldn’t opt for the exception catching of the lists calls but rather a pre-check, or toss the check ‘up’ the callstack by requiring, for example, the list argument to your function to be List=[_|_] instead of just List to enforce a Cons cell instead of a Nil cell.
Basically, behave like
lists:foldl/3but don’t treat empty lists as a special case.
I’m not sure I agree, those are different issues with different exceptions. More I would argue that the exceptions should not be caught at all to begin with as malformed input was supplied to the function and thus who knows what other bad data there is, this is part of OTP’s Let It Crash philosophy, and exceptions are indeed “exceptional” events, not for standard control flow like they are being used here. Plus adding those guards may seem easy to something like map, but that is going to incur a cost on one of the hottest code paths in the entire system, not sure it’s worth it (although with the new JIT in OTP24, who knows, benchmark?).