Variable instances (Re: Trace on Variable assignment)

[Ulf Wiger]

On Thu, 9 Nov 2000, Robert Virding wrote:

>I ALWAYS try to explicit and name the first occurrence as XXX0 and last
>occurrence as XXXn, and make sure I NEVER number variables which are not
>changed.  Just to make it easier to see which variables are meant to be 
>changed.

Yes, this is a sound approach. But it doesn't really address the
problem of identifying the type of bugs I described.

Using the 'unused_vars' option would not, for example catch the "bug"
in application_controller, since all variables are in fact used.


>I think you should be very careful when adding a new syntax for 
>something which is not a new feature.  These are still just variables.

Of course one should be careful. I'm merely making a quick suggestion.
But I don't really understand the "still just variables" argument.
Just like we've added a syntax for addressing part of a data structure
(X[N] could of course easily be interpreted as trying to address the
Nth element in an array), we'd be adding a notion of "history" to a
variable, instead of just trying to give hints using a loose naming
convention. 

Since an instantiated variable cannot be changed - and we do in fact
often want to be able to "update" a data structure - adding a notion
of instance numbering doesn't seem too far-fetched to me.

(Not to say that I'm 100% convinced that my suggestion is the best
one. It may indeed create more problems than it solves.)


>Due to Erlang's (lack of) scoping there could be problems with such a 
>scheme.  

If you say so. 
You're welcome to educate me about what those scoping problems would
be. After all, these are still just variables. ;)


>How hard should lint handle these things?  Is it an error to 
>write?
>
>	X[3] = foo(X[2]),
>	X[10] = bar(X[3]),

Uhmm, it probably shouldn't be. However,

        X[3] = foo(X[2]),
        X[10] = bar(X[2])

should be considered suspicious. Lint would catch that, though. I
didn't know about the 'unused_vars' option. Another way to go could be
to implement some "variable highlighting", similar to the parens
matching in emacs. This would make it much easier to see that your
numbering is not correct.



>If this is really something which people would like lint to check and 
>warn I would prefer just to use the variable-name-ending-with-index 
>convention.

Meaning that Lint should split atoms and try to make sense of your
naming conventions? Then, code like the following from snmp_misc.erl
would be in for a surprise:

is_tmask_match(TAddr1, TAddr2, []) ->
    true;
is_tmask_match([H1 | T1], [H2 | T2], [M1 | M2]) ->
    if
        (H1 band M1) == (H2 band M1) ->
            is_tmask_match(T1, T2, M2);
        true ->
            false
    end.

/Uffe
-- 
Ulf Wiger                                    tfn: +46  8 719 81 95
Senior System Architect                      mob: +46 70 519 81 95
Strategic Product & System Management    ATM Multiservice Networks
Data Backbone & Optical Services Division      Ericsson Telecom AB