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

[Eric Newhuis (personal)]

I appreciate all your comments.

I still don't like temporary variables like X or whatever because they contain no semantic quality and there is a tension between short names to make the pattern obvious and longer names for reunderstanding.

(Oh, I write plenty of small functions.  Its small functions all the way down.)

But I should stop interrupting you with something so trivial so you can get those frames implemented.  I loathe the record syntax.

On May 18, 2010, at 10:01 PM, Richard O'Keefe wrote:

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