[erlang-questions] I think I wish I could write case Any of whatever -> _ end.

[Richard O'Keefe]

On May 18, 2010, at 3:25 PM, Eric Newhuis (personal) wrote:
>
> And the reconstruction of a small tuple bugged me.  Your suggestion  
> shortens this to something arguably easier to type.
>
> case X = find(...) of
> 	error ->
> 		{ok, Default};
> 	{ok, Value} ->
> 		X
> end.

There are two things here.  One is that it gets even simpler:
Value can be replaced by a wild-card.  The other is that the
Haskell idiom for something like this would be to define a
function

	error_default(X = {ok,_}, _Default) -> X;
	error_default(error,       Default) -> {ok,Default}.

and then write

	error_default(find(...), Default)

If the Default is an expression which you don't want evaluated at
all in the normal case, you might prefer a macro.
>
> ...without the apparent overhead of reconstruction.  (Is it a moot  
> point due to a clever compiler?)

I don't know and I don't care whether the compiler is that smart or
not.  What I care about is whether a HUMAN reader can see that the
value that is returned is the value of find(...).
>
> But I guess I am still concerned about suggesting this as a general  
> programming idiom because it introduces a temporary variable.

In the name of suffering humanity,
WHAT IS SO BAD ABOUT TEMPORARY VARIABLES?

I grant you that there were software engineering proscriptions of
"temporary variables" in the sense of scratch variables that got
reused over and over with no specific semantics of their own.
But the variables we are talking about here are no more "temporary"
than any other Erlang variables.  If you mean that the variable is
used over a very narrow range, that's the direct *opposite* of
what the preaching against temporary variables was about, and there
is no harm in it at all, as long as you choose your names well.

>  And as such one would need to study pre- and post-logic to avoid  
> accidental use of the same variable name to name something different.

I'm sorry, but
(A) this is trivial.  Tell your editor "mark clause as region".
     [A simple hack for this is to go back to the first line that
     starts with a letter, apostrophe, or dash, then forward to just
     before the next such line.  I don't actually have this command
     at the moment, so I'd do Ctrl-_ Meta-Ctrl-R, Ctrl-@, Meta-Ctrl-R.]
     Then tell your editor "list variables in region".  [I don't have
     this at the moment, but I do have code for Prolog that I could
     adapt to do it.]  The Smalltalk IDE I often use already has
     "list variables in scope".

(B) Even without that, it's trivial.  Mark the region as before,
     then "find word within region".  Don't find it?  You're safe.

(C) I am at a loss to think of what kind of programming would make
     this a problem.  You are making up a name to stand for a meaning
     that doesn't _have_ a name yet.  Of *course* it gets a name that
     is different from the other names; it *means* something different
     so you give it a different name automatically.

X is just an example that's been used in a vacuum.
In real life, with real examples, in reasonable Erlang code,
there shouldn't be a problem, especially if you use little
functions like the error_default/2 example above (which can be
inlined by the compiler).
>
> I'd not have this concern if Erlang had a LET construct:

True.  You would have a different concern, that of accidentally
hiding a variable you needed to refer to.  It wouldn't be
substantially different.

> So apparently my idea isn't so great.  And I also don't have a  
> satisfying temporary-free and reconstruction-free solution.

I don't have any solution to the problem of programming Erlang
without using the letter 'e' either.  I'm not worried about that.

I don't see any problem with introducing variable names
as long as they are meaningful in context.  That's not Haskell
style, but Erlang isn't Haskell.

I don't see any problem with moving stuff out into other functions
that are then inlined, above all, if the schema is one you can use
again, it's a _good_ thing to do that.  "Temporary variables" that
are in another function entirely aren't any problem, are they?

I think this is one huge issue:

	DON'T BE SCARED OF SMALL FUNCTIONS.

Oh, and let's have real examples, please!

>