principle of least surprise

[Martin Bjorklund]

"Richard A. O'Keefe" <ok@REDACTED> wrote:
> 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')?

What't the point of having two different (three if you count ; and ,)
ways of saying and/or?   You've already given the answer:

> >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.

What can I say...  

> 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) -> ... .

This isn't really useful if I have more than just a few functions
operating on this type - I would have to do 

 f({X,Y}) ->  ... g({X,Y}) ,...
 f(X) when is_atom(X) ->  ... g(X) ,...

or

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

safe_f(X) -> ... g(X).

for all functions.


> 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.

I'm just trying to do some abstraction with the tools we have today
(well it didn't work...) - exactly what you say.

> Do I have to mention that abstract patterns could have solved the original
> problem with ease?  Maybe I do.

But you just said that what i tried to achieve was odd.  With your
abstract patterns I'm suddenly allowed to think in these odd ways?



/martin