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

[Robert Virding]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20070910/1318363c/attachment.htm>