[erlang-questions] eep: multiple patterns

[Richard A. O'Keefe]

On 28 May 2008, at 12:36 am, Andras Georgy Bekes wrote:

> Hi,
>
>> To me, what we can write now in Erlang as it stands,
>> separating "what are the actions" from "what are the names for the
>> actions", is easier to read and understand than anything using
>> multiple patterns would be,
>
> OK, you showed us (again?) that a possible use of multiple patterns  
> can
> be substituted with something else. It always can be done, and
> everybody knew that.
>
> Following your way of thinking, we'd conclude that the 'case'  
> construct
> is not needed because it can be substituted with auxiliary functions.
> Still we have the 'case' construct and like it.

*NO*.  The argument is not "we can do without it"
but "we can *EASILY* do without it" and
"doing without it can lead to BETTER code".

I am not interested in some kind of academic purity or minimalism.
What bothers me is people adding kluge upon kluge to a language
until it is as complicated as C++ and programs written in it as
unreadable as C++ can far too easily be.  (Have you ever tried
reading the Boost sources?)

What I showed you was not that "a possible use of multiple patterns
can be replaced by something else" but that it can EASILY be done
and that the code is easier to read when you have done it.
>
>
>> not because multiple patterns are a bad idea as
>> such, but because combining multiple *complex* patterns into a single
>> match makes the code harder to read.
> That's subjective. To me, the multiple patterns version reads better.

"Subjective" is not the same as "idiosyncratic" or "unmeasurable".
We _can_ measure these things.

>
>
>> Multiple *simple* patterns might make for a more interesting example.
> OK, you asked for real-life examples. OK, simple pattern.
> Here it is, straight from AXD301. I've replaced the "interesting"  
> parts
> with foo, bar and baz. Everything else is original.

GREAT!
>
>
> ----------------------------------------
> case classify_Foo(Foo) of
>   undefined_Foo -> bar(); % lots of code here
>   {meaningful_Foo, Bar, Baz} -> baz(Bar,Baz) % lots of code here
> end,
> ...
> classify_Foo(undefined) ->
>    undefined_Foo;
> classify_Foo({undefined, _, _}) ->
>    undefined_Foo;
> classify_Foo({Bar, Baz}) ->
>    {meaningful_Foo, Bar, Baz};
> classify_Foo({Bar, Baz, _}) ->
>    {meaningful_Foo, Bar, Baz}.
> ----------------------------------------
>
> How do you like it?

I must say that the _Foo business is hard to read;
I can't help seeing {meaningful Foo, Bar, Baz}.

Cleaning it up as
     case classify_foo(Foo)
       of undefined ->
          bar()
        ; {meaningful,Bar,Baz} ->
          baz(Bar, Baz)
     end,
     ...
classify_foo(undefined        ) -> undefined;
classify_foo({undefined, _, _}) -> undefined;
classify_foo({Bar,     Baz, _}) -> {meaningful,Bar,Baz};
classify_foo({Bar,     Baz}   ) -> {meaningful,Bar,BAz}.

I like it *fine*, especially if the arms of the case are
split out as separate functions (should that be possible).

Something I particularly like about this is that I can
sort the patterns in classify_foo so as to bring out
similarities between them, without being constrained by
any need to group together things with the same consequence.
In particular, *this* way it is easy for me to rearrange
the patterns, as in fact I have done, to make the overlap
between
	{undefined, _, _}
and	{Bar,     Baz, _}
obvious.  Now that I can see it, I can wonder what
{undefined,Baz,_} is supposed to do, and then whether
{undefined,Baz} is also possible, and what IT should do.

In short, doing it the way I recommend clearly in this
case has the potential to lead to more insight about the
data structure and quite possibly more reliable code,
because it makes it easier for me to *see* what the heck
is going on (in both places, as it happens).
>
> I prefer the multiple patterns version.

Yes, but why?  What does it help you to SEE that is useful
for programming and maintenance that the other approach
doesn't help you to see at least as well?
>
>
> (Don't tell me the problem is with the data structures. We all know
> AXD301 is garbage :-) but still, our users like it.

A program need not be garbage in order to profit from overhauled
data structures.  The Quintus Prolog compiler was a great piece of
work, but spending two weeks of work cleaning up its data structures
bought a 20% speed up.  It's one kind of refactoring.