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

[Henning Diedrich]

But if it was another symbol? Say ~.

Richard O'Keefe wrote:
>
> On May 18, 2010, at 2:00 AM, Eric Newhuis (personal) wrote:
>
>> For the record, I might still disagree, so far.  I'm not sure.  
>> Simply for argument's sake...
>>
>> The context in which this might be maximally useful is the following.
>>
>> case some_module:some_function(...) of
>>     {some, pattern} -> _;
>>     {some, other, pattern} -> _;
>>     _ -> whatever
>> end.
>
> What is wrong with
>
>     case X = some_module:some_function(...)
>       of {some, pattern} -> X
>        ; {some, other, pattern} -> X
>        ; _ -> whatever
>     end
>>
>> Note that I belong to the school of philosophy that suggests that the 
>> number of temporary variables should be minimized.
>
> By using the wild card, you have *NOT* minimised the number of temporary
> variables.  All you have done is to carefully deprive your reader of any
> clues as to what it is about.
>
>
>>  I don't understand why the above would be called wild-card abuse.
>
> Because the whole *point* of the wild-card is that each and
> every occurrence of "_" should represent a DIFFERENT variable.
> That's what it means in Prolog, Mercury, Strand88, Parlog, GHC,
> ML, Haskell, Clean, ...  Every time, a different variable.
> But you are relying on the "_" in each arm of the case being
> the *SAME* variable.
>
> You are also creating great confusion.
> Suppose I have
>
>     case foo()
>       of {ping,_} -> _
>        ; {_,pong} -> _
>     end
>
> The wild cards *following* the arrows are the *same* variable;
> what about the wild cards inside the patterns?  If not, why not?
>
> What if I write
>     case foo() of _ -> case bar() of _ -> _ end end
> Does this mean the same as
>     case foo() of X -> case bar() of X -> X end end
> or    case foo() of X -> case bar() of Y -> X end end
> or    case foo() of X -> case bar() of Y -> Y end end
> or what?
>
> There's another point.  In Erlang as it stands, _every_
> variable _without exception_ must be visibly present at
> the point where it is bound.  (Wild cards are no exceptions
> to this rule).  You are introducing a new reading of "_"
> that violates this rule.  If you want to think of the
> variable as bound in the pattern, write
>     case Expr
>       of X = Pattern when Guard -> X
> If you want to think of the variable as bound in the head,
> write
>     case X = Expr
>       of Pattern when Guard -> X
> In either case, the variable X is *visibly* bound.
>
>>  It is clear from context that the wild-card represents something 
>> other than matching.
>
> Yes, but we already *have* something we can use for this purpose.
> Ordinary variable names.
>
>
>>  We've seen this idea before.  There are those grammars that expose 
>> variables whose value is whatever matched.
>
> I have no idea what you are referring to.  Can you explain?
>
> "Exposing variables" is different from "invisibly binding anonymous
> variables".
>
>>
>> I suppose the following is where this great idea of mine might break 
>> down.
>>
>> case some_module:some_function(...) of
>>     {some, pattern} ->
>>         {encapsulated, _};
>>     {some, other, pattern} ->
>>         {another, _, encapsulation}
>> end.
>>
>> Although I still don't have a problem with that.
>
> You may not.  I do.
>
>>  From context I know that the right hand side of the arrow isn't 
>> pattern matching.
>
> You as author may; your reader WILL have to work harder in reading
> to find out what the context *is*, especially if (as is often the
> case) the arrow is on the previous screen.
>
> This would be better as
>
>     case X = some_module:some_function(...)
>       of {some, pattern} ->
>              {encapsulated, X}
>        ; {some, other, pattern} ->
>              {another, X, encapsulation}
>     end
>
> There is not one of your examples that would not be massively improved
> by introducing a named variable, even a literal X.
>>
>> I guess where readability might break down is in nesting:
>>
>> case some_module:some_function(...) of
>>     {some, _, pattern} -> % _1
>>         case _ of ->  % _2
>>             {some, great, pattern} ->
>>                 not_so_bad;
>>             _ -> % _3
>>                 {_, Kind, _} = _, % _4, _5, _6
>>                 Kind
>>         end
>> end.
>>
>> Although I can still read the above once I learn that underscore 
>> ('_') is context sensitive.
>>
>> _1 :: any()
>> _2 :: {some, any(), pattern}
>> _3 :: {some, any(), pattern}, not {some, great, pattern}
>> _4 :: some
>> _5 :: pattern
>> _6 :: _3
>
> If I want to play at silly puzzles I do the Sudoku problem in the
> newspaper.  If I'm reading a program, I do *NOT* enjoy pointless
> stumbling-blocks placed in my path to understanding.
>
> Let's rewrite your example.
>
>     case some_module:some_function(...)
>       of {some,Kind,pattern} ->
>              case Kind
>                    of great -> not_so_bad
>               _     -> Kind
>          end
>     end
>
> There is now *no* puzzle-solving for the reader.
>
> Let me raise my usual refrain:
>     let's have a REAL example.
>
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>