[erlang-questions] style question - best way to test multiple non-guard conditions sequentially

[Richard A. O'Keefe]

On 21/06/2013, at 5:23 PM, Siraaj Khandkar wrote:
> http://www.gar1t.com/blog/2012/06/10/solving-embarrassingly-obvious-problems-in-erlang/
> http://existentialtype.wordpress.com/2011/03/15/dont-mention-equality/
> http://existentialtype.wordpress.com/2011/03/15/boolean-blindness/

I had those in mind, so thanks for finding them.

There are a number of bug prevention tricks that are unreasonably
effective.  Compare

	class Mutex {
	    ...
	    bool trylock();
        };

	if (my_mutex->trylock()) {
	    // is the lock held here or not?
	}

with

	class Mutex {
	    enum Status {This_Thread_Has_It, Another_Thread_Has_It};
	    ...
	    Status trylock();
	};

	if (my_mutex->trylock() == Mutex::This_Thread_Has_It) {
	    // we don't need to think here; we _know_.
	}

And then in functional languages, so often we find that there's more
information to return in at least one of the cases.  Harper points
out the benefits of
	case List
          of [] -> ...
           ; [Head|Tail] -> ...
	end
compared with
	if null(List) -> ...
	 ; true -> Head = hd(List), tl = tl(List), ...
	end

I think there's a felt difference (not necessarily a fundamental difference)
between languages with pattern matching -- where constructing "rich answers",
returning them, and dispatching on them *feels* cheap -- and languages
without -- where none of these is true.

For example, even though I'm suspicious of Booleans, my Smalltalk code is
riddled with #ifTrue:ifFalse:.  (About 6% of the SLOC, in fact.)  A good
deal of that has to do with the fact that you can't return multiple
answers at the same time from a Smalltalk method without creating a new
object.  (The fact that Smalltalk didn't have var parameters was
excusable in an experimental language; the way Java made their absence
a religious dogma is not.  One of the things C# got right.)