[erlang-questions] 回复： How to make a short circuit in erlang ?

[Richard A. O'Keefe]

On 26/03/2013, at 4:24 PM, 饕餮 wrote:

> hmmmmm
> Something I just don't agree.
> I use Something == false.

This is, I repeat, Bad Style in ANY Programming Language.

It has been bad style ever since Algol got the Boolean type in
1960 and Fortran got the LOGICAL type in 1961.

> Because I do not name the variable like Is_Something_Right (Apologize for my mike).

Why do you think that a bad choice of names justifies inappropriate comparison?

> !Is_Something_Right could be a better code style.
> !Something , in my opinion, is not better than Something == false.

It is, if Something is well named.

The important thing here is that Boolean values are part of a Boolean
_algebra_, and by avoiding the natural operations of that algebra,
you are making combinations of Booleans __hard to think__ when they
need not be.

I must point out that having Boolean-valued variables _at all_ in Erlang
is definitely odd.  It's possible.  It's not _wrong_.  But it _is_ odd,
and there is usually a more idiomatic way to do it.
> 
> I have see this code style in my project as you write.
> example(Foo, Bar, Ugh) ->
>     case {Foo, Bar, Ugh}
>       of {false, _, _} -> . . .
>        ; {true, false, _} -> . . .
>        ; {true, true, false} -> . . .
>        ; {true, true, true} -> . . .
>     end. 
> But when look at the {true,true,false}.
> I still need to check which one is true , and which is false (I'm just stupid as a duck).

When you look at the {true,true,false} case, you can *see* which one
is false (Ugh) and which are not (Foo, Bar).  If you can't, you have
too much code in one place.

Of course, something like this should be encoded using one expression
with multiple values rather than several Booleans. 

> And There could be 8 different status.
> That means I should write 8 entry for 3 judgement

No, for three judgements you need three entries.

Let's switch to Haskell for the moment.

Let t1, t2, t3 be three arbitrary expressions of type Bool
and e1, e2, e3, e4 be four arbitrary expressions of a
common type alpha.

Then
	if t1 then e1 else
	if t2 then e2 else
	if t3 then e3 else t4
and
	case (t1,t2,t3) of
	  (True, _,    _)     -> e1
	  (False,True, _)     -> e2  
	  (False,False,True)  -> e3
	  (False,False,False) -> e4

are equivalent.  In fact, a good Haskell compiler will probably generate the
same code for both of them.

Both examples make FOUR judgements based on THREE variables.

In Erlang, they are only equivalent in the absence of exceptions and
side effects.

But the scheme as outlined does *NOT* have 2^n branches; it has
*exactly* the same number of branches as an 'if' nest would have.
So your argument for disliking it is unsound.

> I just wonder is there any way like return in other language could just return and ignore the step below.

Many other programming languages do _not_ have a 'return e;' statement.
In particular, functional languages such as ML, Clean, Haskell, and F#
don't.  From a web page about F#:

	One of the limitations of F# is that it doesn't very well
	support some of the advanced imperative language constructs
	such as break, continue or imperative style of returning
	value from a function, meaning that you can't write something
	like return false in the middle of the function.  This has
	good reasons.

> And Now I know there are no way to do like that.

A real example of something you need to write would be really really useful.

Here's a little example.
We are given two tuples Whole and Part and want to find
the smallest integer I such that Whole[I..I+tuple_size(Part)-1] = Part.
We want to return 0 if there is no such I.  We might begin

    index_of_subtuple(Whole, Part)
      when is_tuple(Whole), is_tuple(Part), tuple_size(Whole) >= tuple_size(Part) ->
        . . . straightforward case . . .;
    index_of_subtuple(Whole, Part)
      when is_tuple(Whole), is_tuple(Part) ->
        0.

You are probably used to the idea that a function can have only one body,
which is not true in Erlang (or Haskell, or ML, or Clean, or F#, . . .).