principle of least surprise

[Richard A. O'Keefe]

mbj@REDACTED wrote:
	As for andalso and orelse, I realize that it probably won't happen,
	but if it did, is it really such a big thing?

Yes.

What exactly is WRONG with 'andalso' (= Dijkstra's 'cand', C's '&&',
Haskell's '&&', ISO Pascal's 'and_then', Ada's 'and then', SML's
'andalso') and 'orelse' (= Dijkstra's 'cor', C's '||', Haskell's '||',
ISO Pascal's 'or_else', Ada's 'or else', SML's 'orelse')?

>60 years of programming languages have shown us that it is a bad idea
or use plain 'and' and 'or', because people are never quite sure what
they do.  (Blame this on Fortran, which deliberately refused to say,
and Pascal, which followed Fortrans' lead.)

If you want to get rid of something, get rid of plain 'and' and 'or',
which for use in ordinary expressions are user-definable.

	> What about allowing 'orelse' and also 'andalso' in guards?
	> That will probably happen one day.
	
	Better than nothing of course, but wouldn't it be great to fix this
	mis-feature and make the language better?
	
'andalso' and 'orelse' are not misfeatures.  They are useful and above
all not misleading.  If we can have ',' and ';' in guards, we should
certainly have 'andalso' and 'orelse' there.

But the real problem, it seems to me, is that someone is trying to
do something very very odd.

Having a type that is either an atom or a pair?  Fine, no problems.
It's easy enough to write functions

    f({X,Y}) -> ...;
    f(X) when atom(X) -> ... .

But having a function where the argument could be that OR something else?
Not so fine.  Not fine at all, really.  A function argument should have one
clear conceptual type.  The language is trying to tell you you are doing
something that could be better done other ways.
	
Do I have to mention that abstract patterns could have solved the original
problem with ease?  Maybe I do.

Abstract patterns could have solved the original problem with ease.

    #funny_type(X) when atom(X) -> X;
    #funny_type(X = {_,}) -> X.

    seriously_weird_function(#funny_type(X), ...) -> ...;
    seriously_weird_function(#some_other_type(X), ...) -> ... .

Death to macros!  _There's_ a misfeature!