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

[Peter K Chan]

Good point. I just ran some examples myself and I see that it may be fundamentally difficult to give straightforward error message in a language that does assignment as side effect of matching.

I think the dichotomy stamps from the fact that the compiler wants to bind values as part of pattern matching, where as the programmer, coming from another mainstream programming language, thinks of the statement as assignment-oriented, with the possibility of failing a pattern match.

I don't know of a good way to give more intelligent error message, especially in the current highly-compacted error message format (i.e. {{badmatch, error, ...}}). To give a good explanation, the compiler will probably have to give out a full paragraph of text, explaining which part of the match failed and what variable cannot be assigned.

Peter

________________________________________
From: Robert Virding [mailto:rvirding@REDACTED] 
Sent: Sunday, September 09, 2007 7:25 PM
To: Peter K Chan
Cc: Dustin Sallings; erlang-questions@REDACTED
Subject: Re: [erlang-questions] What is wrong with this list?

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: 

{X,Y} = some_call(...)

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. 

Robert
On 05/09/07, Peter K Chan <peter@REDACTED> wrote:
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. 

Peter

From: Dustin Sallings [mailto:dustin@REDACTED]
Sent: Tuesday, September 04, 2007 4:47 PM
To: Peter K Chan
Cc: erlang-questions@REDACTED 
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}). 

        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. 

        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.

--
Dustin Sallings



_______________________________________________ 
erlang-questions mailing list
erlang-questions@REDACTED
http://www.erlang.org/mailman/listinfo/erlang-questions