Variable instances (Re: Trace on Variable assignment)
Thu Nov 9 13:46:51 CET 2000
Ulf Wiger <> writes:
>On Fri, 3 Nov 2000, Ulf Wiger wrote:
>>X = foo(...), %  is implicit
>>X = bar(X),
>>X = foo(...), % \0 is implicit
>>X\1 = bar(X),
>>would allow trace on "changes" to a variable, and also introduce a
>>standard way of describing something that occurs frequently in
>>most Erlang code I've seen.
>Since I posted this without thinking much, I paused and thought about
>One common source of bugs (and very hard to find) is when "changing" a
>variable and forgetting to pass the latest instance. An example from
>a compiler could easily produce a warning stating that we're passing
>an old instance of S, since this is almost always a bug, and can
>easily be avoided in the cases when it it's intentional.
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
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.
Due to Erlang's (lack of) scoping there could be problems with such a
scheme. How hard should lint handle these things? Is it an error to
X = foo(X),
X = bar(X),
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. Lint already checks for singeton variables if you ask it,
just use the option 'warn_unused_vars'. It is, however, a bit of a
sledgehammer. It ignores variables starting with "_", eg. _Temp.
Robert Virding Tel: +46 (0)8 545 55 017
Alteon Web Systems Email:
S:t Eriksgatan 44 WWW: http://www.bluetail.com/~rv
SE-112 34 Stockholm, SWEDEN
"Folk säger att jag inte bryr mig om någonting, men det skiter jag i".
More information about the erlang-questions