Three wishes

[Richard A. O'Keefe]

In answer to the question
	> 	Is there any case in which it is a "must have"?

I wrote:
	> Why yes, in the common case of things like
	> 
	> 	if X > Y -> Sign = 1,  Abs = X - Y
	>          ; X < Y -> Sign = -1, Abs = Y - X
	>          ; X ==Y -> Sign = 0,  Abs = 0
	>         end,
	>         ... use Sign and Abs ...
	> 
	> where the *point* of the conditional is to bind several variables
	> rather than to compute a value.
	
My argument is that we "must have" this feature because it is USED.
The person who hates it, hates it because it is USED.

Samuel Rivas <samuel@REDACTED> replied:

	Well, it is not really a "must" but a "could".

One of us is misunderstanding "must have".  I think that a feature which
was designed for good reason (familiarity to Prolog and Strand programmers)
and which is in active use by many people is a "must have" because I don't
believe in kicking innocent users in the teeth.  (The slogan I proposed
for the ISO Prolog committee, which they explicitly rejected, was
"Non calcitrandus in dentes artifex".)

	Personally, I feel matching the if result is more erlangish

I would dispute that.  Part of the point here is that a dumb compiler
can generate good code WITHOUT having to slog through an analysis to
determine that certain tuples don't *really* need to exist.

	test(X, Y) ->
	    {Sign, Abs} = if X > Y ->  {1, X - Y};
			     X < Y ->  {-1, Y - X};
			     X == Y -> {0, 0}
			  end,
	    ... More sentences ...
	
This
 - shoves a block of code way over to the right for no good reason
 - is more error-prone than the current practice (if you forget to
   bind a variable in one of the cases, the compiler will warn you
   downstream that you are trying to use a variable that you mayn't,
   while if you get the number of elements in one of these tuples
   wrong, you will get a run-time error instead, IF you test well)
 - forces you to write the expressions in the same order in each case,
   instead of the order which is most natural for each case
 - moves the names a long distance away from the values they are bound
   to, so that it is MUCH harder to see which variables are bound to
   which values
 - introduces a new family of mistakes where you get the number of
   expressions in each tuple right, but the order wrong in one of them

None of this strikes me as particularly "Erlangish", and it seems to me
one of the merits of the language that it offers you a choice here.

	I see this more as a potential "best practice" than a reason
	for the compiler to print a warning.

It's odd to see something which separates names from values and makes
more mistakes not only possible but likely described as "best practice".