[erlang-questions] comma vs andalso
Mon Jul 20 18:15:43 CEST 2009
----- Original Message ----
> From: Richard Carlsson <>
> > 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.
More information about the erlang-questions