[erlang-questions] comma vs andalso

[Thomas Lindgren]

----- Original Message ----
> From: Richard Carlsson <richardc@REDACTED>
>...
> > It's _still_ the case that almost no non-trivial expressions
> > can be moved into a guard.
> 
> True. But every bit helps. Ive never found "this does not solve all
> problems" to be an argument for not making a partial improvement
> (as long as it does not create an obstacle for future development).

In my opinion a very dangerous attitude in a language like Erlang, where mistakes in design get set in stone. Off the top of my head:

1. records eternally forced to be tuples because of the chosen API;
2. and/or being strict, meaning we had to introduce andalso/orelse;
3. packages vs module names as atoms leading to unsoundness;
4. (the whole guard mess with all its needless duplication, as discussed elsewhere)

or the following:

....
> Yes, however, there was already a similar rule in place since
> ancient times, and it stated that in the case you describe, the
> built-in function takes precedence. Bummer. (We are now slowly
> trying to phase out this old rule, though, taking baby steps.)

I do think that rule has been criticized for being wrong basically since day one. (At least I have considered it an awful bug since I first encountered it; it makes a hollow mockery out of scoping) So it's good to hear it's getting fixed.

> Neither necessary nor sufficient, but likely. It's a game of
> probabilities. I _had_ seen several existing modules that used the
> name list(Xs), and float(X) was already in use as a BIF for casting.
> In comparison, the is_ convention was much less likely to cause
> clashes (indeed, I recall no reports of any such when we introduced
> the new names). And the convention has kept working for those type
> tests that were added later, e.g., is_boolean(X), is_bitstring(X).

Um, you do realize that the current deprecation of short tests is breaking miles and miles of code? We're hardly taking the path of least resistance here.

Best,
Thomas