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/3 but 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?).

Hear hear! I really like the recent changes. ^.^

Lol, why do I want a link to this discussion? ^.^

In this case yes. Most good type systems can enforce non-emptiness, and erlang likes to pretend it does as well. It’s on the caller to ensure they are passing in good data in that case. I’m a fan of static typed systems that can actually enforce this though, lol. Dialyzer helps a little bit at least. Hmm, does dialyzer catch that case actually?

Thank you for the super-detailed answer(s), @OvermindDL1 !!

I should’ve stated that I was testing this on OTP23, you’re right.

In any case, Lukas Larsson (from the OTP team) already replied in Medium with that regarding what they’re doing to improve error descriptions… and it’s GREAT!!

Finally, to some things in your message…

100% agree! I actually had to explain this very same thing when discussing the robot butt article on lobsters recently.

To be clear: Are we talking about the same different issues here? What I tried to say was that calling a function that works normally with empty lists, with an empty list and another wrong argument, should not behave as if it was called with something that’s not a list. Instead, it should behave as if it was called with a non-empty list. Do you still think that calling it with a bad fun and an empty list is a different issue than calling it with a bad fun and a non-empty list?

Of course, you’re right. But I was exemplifying.

Yeah, I agree again. That’s why the section in the article is called Is this a Problem? and not This is a Problem. This is clearly a made up problem just for the sake of arguing, except for the confusing error descriptions in the shell, which is what Lukas and the OTP Team are fixing right now