[erlang-questions] How about a new warning? Was: Re: trouble with erlang or erlang is a ghetto

[Håkan Huss]

On Thu, Aug 4, 2011 at 00:17, Robert Virding
<robert.virding@REDACTED> wrote:
> I am assuming that the check only applies for variables in matches with '=' and not in case/receive patterns. In that case I would not mind having such a warning turnable on/off at will. I seldom test for values in '=' matches, only in case/receive.
>
There is one area of code where I use matching of bound variables with
= a lot, and that is in ct test cases. A typical example is:

    ...
    Alarms0 = get_current_alarm_list(),
    <code that should not raise an alarm>
    Alarms0 = get_current_alarm_list(),
    <code that should cause an alarm to be raised>
    Alarms1 = get_current_alarm_list(),
    verify_alarm_raised(Alarms1, Alarms0, <alarm that should be
present in Alarms1 but not Alarms0>),
    <code that should clear the alarm>
    Alarms0 = get_current_alarm_list(),
    ...

While ROK's crash_if_different could be used here, my personal opinion
is that the test code as written expresses the test better and does
not require that I introduce a bunch of new variables to hold old
values.

In normal code, however, I use this very sparingly. Then again, I
seldom experience this as a problem. Thinking back, most of the times
I've been bitten by this is probably in case clauses, especially when
adding code. Typically, when using canonical variables like Pid,
Reason or Result without checking that the code isn't in a branch
which already uses it. And since I agree with Robert that case and
receive should not cause a warning, I don't really feel the need for
it.

Regards,
/Håkan

> The emacs colouring is difficult given how erlang handles variables and evaluation ordering etc.
>
> Robert
>
> ----- Original Message -----
>> Actually I like things as they are. My eye is trained to see bound
>> and
>> free occurrences of a variable.
>>
>> On the other hand it would be *excellent* if the color coding in
>> emacs
>> (whatever) was changed to reflect the
>> binding status of a variable.
>>
>> If variables in the LHS of an equals were colored green if they were
>> unbound and red
>> if bound then one would see at a glance what was intended.
>>
>> (( assuming you're not red-green color blind that is )) - or set the
>> variables in a different type face.
>>
>>
>> /Joe
>>
>>
>>
>> 2011/8/3 Frédéric Trottier-Hébert <fred.hebert@REDACTED>:
>> > On 2011-08-02, at 01:59 AM, Richard O'Keefe wrote:
>> >
>> >> 2. Is matching against an already-bound variable a check we want?
>> >
>> > To me, matching against an already-bound variable is is a valid
>> > assertion, as much as 'ok = function_call()' might be, and as
>> > implicit as '{ok, Pid}' or '{error, already_started}' might be.
>> > Matching on already-bound variables is part of my standard code
>> > when trying to crash early when possible, and also part of many
>> > basic test suites that simply do pattern matching here and there.
>> > To me it's as basic as using the same variable twice in a single
>> > pattern (f([A,A,B,B|_]) when A =/= B -> ...), or something similar
>> > with records.
>> >
>> > I would likely not use the check at all, and if it were to be
>> > added, would prefer it to be a compiler argument (which could be
>> > enabled in -compile(...).) I foresee little use of such warnings
>> > for myself and would dislike to see it becoming a default setting.
>> >
>> > --
>> > Fred Hébert
>> > http://www.erlang-solutions.com
>> >
>> > _______________________________________________
>> > erlang-questions mailing list
>> > erlang-questions@REDACTED
>> > http://erlang.org/mailman/listinfo/erlang-questions
>> >
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>