Three wishes

[Samuel Rivas]

Richard A. O'Keefe wrote:
> 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"

  We had different interpretations, I understood "must have" as a thing
that is needed to write code that couldn't be wrote otherwise (in a
block with similar amount of sentences). I agree there is no point to
disable this feature breaking loads of old code and I also agree that,
in this matter, exported variables are a "must have".

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

  I think basing your coding style in the compiler
shortcomings/limitations is not a good idea if it obscures the code. The
point here is whether exported variables should be avoided or not basing
in the clarity of the programs.

> 	test(X, Y) ->
> 	    {Sign, Abs} = if X > Y ->  {1, X - Y};
> 			     X < Y ->  {-1, Y - X};
> 			     X == Y -> {0, 0}
> 			  end,
> 	    ... More sentences ...
> 	
> This
>   [ ... Several reasons against previous block ... ]
>
> 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.

  Of course there are points against both approaches. On the other hand,
I like better considering an if/case block as a box that returns something
rather than a block that *does* something. In my view, it is
more functional: you can easily change the if for a function.

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

  I said _potential_ :). If hundreds of reasons encouraged one of the two
coding styles, that would probably be a "best practice". Otherwise, it
will remain, as I said, a matter of taste.
-- 
	Samuel