I think the problem is to realise that there is NO difference between assignment and matching. In fact there is no assignment, only matching. Therefore having different errors for them is plain wrong. Also how would you handle the case of say:

<br><br>{X,Y} = some_call(...)<br><br>where both X and Y are unbound? In one respect it is an assignment to multiple values, but it is also definitely a match pulling apart a value. Even if you were to say that if there were unbound variables then it is an assignment you would still get into problems with code like:

{ok,X} = ... or if you had patterns with some variables bound and some unbound. Sorry if this answer seems a little harsh, but I wouldn't want to introduce a concept which doesn't exist into an error message.

<br><br>Robert<br><br><div><span class="gmail_quote">On 05/09/07, <b class="gmail_sendername">Peter K Chan</b> <<a href="mailto:peter@oaktop.com">peter@oaktop.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Dustin, As someone who has known Erlang for a while, the error message would probably not be helpful (if even possible). But as a newbie, knowing the difference between an assignment and a match can be very helpful. Actually, if the bad match comes from some deep recursion, I think I would appreciate seeing the actual value, even if I know what badmatches in general are.

I do agree that the current error message gives out enough information for debugging purpose, but having seen, more than once, where someone is confused about the matching vs. assignment, I think the more explicit error message would be "nice" to have.

<br><br>Peter<br><br>From: Dustin Sallings [mailto:<a href="mailto:dustin@spy.net">dustin@spy.net</a>]<br>Sent: Tuesday, September 04, 2007 4:47 PM<br>To: Peter K Chan<br>Cc: <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org

</a> Subject: Re: [erlang-questions] What is wrong with this list? 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}).

<br><br>        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:<br>

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.

<br><br>        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.<br><br>--<br>Dustin Sallings<br><br><br><br>_______________________________________________

<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions

</a><br></blockquote></div><br>