Richard A. O'Keefe
Wed Apr 6 01:58:47 CEST 2016
Thank you Doug. Yes - it makes sense. However operator precedence, which
I previously checked, do not specify and & or:
Actually, that section of the reference manual DOES specify 'and' and 'or'.
They are right there in the 4th and 5th rows of table 8.6.
/ * div rem band AND
+ - bor bxor bsl bsr OR xor
This makes no sense to me. I mean, it REALLY makes no sense.
'and' and 'or' are for combining "boolean" values.
The way to *get* boolean values is to do a comparison.
What would have made *sense* would have been to put
'and' and 'andalso' at the same level (and forbid mixing them)
and to put 'or' and 'orelse' at the same level (and forbid mixing them).
If I were daft enough ever to use 'and' or 'or' in Erlang, this would
*certainly* confuse the heck out of me. For the sake of my sanity,
I make sure *never* to use them.
For what it's worth, R has '&&' and '||' which operate lazily on
single logical values, rather like C, and also has '&' and '|',
which are strict and vectorised. In R, & and && have the
same precedence, and | and || have the same precedence, and
confusion would reign supreme if they did not.
More information about the erlang-questions