[erlang-questions] What is wrong with this list?

[David Hopwood]

Dustin Sallings wrote:
> On Sep 4, 2007, at 13:29 , Peter K Chan wrote:
> 
>> I think it would be nice if the compiler can output why a match fails
>> (e.g. {number, 1} does not equal {atom, java}).
> 
>     This could work as an error string along with the badmatch for the
> single case discussed, but what about a case (that is contrived, but
> probably similar to real code I've written somewhere) like this:
> 
>     Pid = some_function(),
>     Pid = other_function().
> 
>     The error message wouldn't be all that useful to you either way
> because on the first line you're capturing a value into a variable, and
> on the second line you're validating the same Pid is returned.  If it
> showed you the value, it'd probably be meaningless to you.  It would
> basically be showing you two different values and saying they're not the
> same.

In cases where this is a bug, it probably *is* often useful to know what
the two values (Pid and other_function() in the second match) are. For
process ids, it is less useful than for other values, but you can still
use them to identify both processes in a debugger. At least this
information can't hurt.

>     You have the same issue in a case, receive, function definition,
> etc... for which you have no matching case.  You don't want to list
> every possible pattern.

That's not a reason not to display the pattern in cases where there can
only be one.

-- 
David Hopwood <david.hopwood@REDACTED>