[erlang-questions] nand problem

[Joe Armstrong]

On Mon, Jan 26, 2015 at 6:26 PM, Hugo Mills <hugo@REDACTED> wrote:
> On Mon, Jan 26, 2015 at 05:21:42PM +0100, Roelof Wobben wrote:
> [snip]
>> b_and(true, true) ->
>>   true;
>>
>> b_and(true, false) ->
>>   false;
>>
>> b_and(false, true) ->
>>   false;
>>
>> b_and(false, false) ->
>>   false.
>
>    You could make this shorter and possibly easier to read with
>
> b_and(true, true) ->
>     true;
> b_and(_, _) ->
>     false.

At which point I feel compelled to ask
do you really really really want

b_and(1, any_old_stupid_argument) to evaluate to false?

by explicitly requiring the arguments of b_and to be true or false
*and nothing else* you ensure that a program calling b_and with stupid
arguments will crash *as soon as possible* which will make debugging
easier. It also enables a whole bundle of compiler optimisations -
making arguments more general than they need to be makes analysis more
difficult
and compiled code more general. The more you tell the compiler, then
better code it can produce.

Yes the program is shorter (good) - but it's not totally correct (bad).

This is not important for small programs, but for huge programs making every
function totally correct is essential - correct well typed code can be written
stuck in a library and forgotten forever - code that does silly things
with silly
arguments is not good programming practise.

b_not should be defined over boolean arguments - any non boolean
argument should raise an exception *immediately* anything else
violates
the principle of least astonishment.

Cheers

/Joe






>    i.e. define the (one) special case, and then just say that
> everything else evaluates to false. You can do something similar with
> b_or.
>
>    Hugo.
>
> --
> Hugo Mills             | Two things came out of Berkeley in the 1960s: LSD
> hugo@REDACTED carfax.org.uk | and Unix. This is not a coincidence.
> http://carfax.org.uk/  |
> PGP: 65E74AC0          |
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>