kers@com.hp.hpl.hplb (Chris Dollin) writes:
> Date: 29 Nov 1995 09:28:39 -0000
>
[AS]
> | Another frequent source of bugs is use of uninitialised lvars which
> | turn up as unexpected occurrences of 0. There should be a compile
> | time debugging option to initialise lvars to have undef objects with
> | the name of the lvar, e.g. so that a bug involving an uninitialised
> | lvars fred would show up as something like "<undef 'lvars fred'>".
>
> My personal and technical opinion is that this is more simply fixed by
> disallowing uninitialised declarations, with an ``old code'' switch to
> allow them (and force initialisation to a suitable undef value).
>
> The occasions on which I have needed to declare a variable but do not
> know what value to give it are so few and far between that I think it
> would be better to disallow it.
That's because you don't use a pattern matcher ????
Anyhow, this sort of thing depends on one's programming style. Some
people like to have all their variable declarations near the top of
each procedure so that gives an immediate indication of some of
what's going on in the procedure, and also makes it easy to check
which variables are and are not used in the procedure. On the other
hand I find myself increasingly writing at arbitrary locations in
procedures things like
lvars xxx = fff(ppp,qqq,rrr....);
What's not so natural perhaps is to use that in a loop where a
variable gets a value every time round the loop. For it might
suggest to some people that something more complex than an
assignment is happening each time round the loop. On the other hand
if you understand that
lvars xxx = ....;
is doing TWO things at once, namely (1) at compile time telling the
compiler something about xxx and (2) at run time doing an assignment
to xxx, then there's no worry about (1) being done each time round
the loop.
Of course, people who don't like "vars" to do TWO things in a
procedure body will probably object to initialised declarations of
lvars, on similar grounds - it uses one instruction to do two
totally different things?
Aaron
There is no loss of generality; one can
> always write a junk value if one is *convinced* that the code cannot be
> written any other way. There need be no loss of efficiency; the compiler
> can optimise out those assignments when it can prove that the values
> will ``never'' be seen.
>
> | There are lots more, all of them more important than banning the use
> | of vars to declare and localise simultaneously and inflicting a lot
> | of trouble in people who have spent several years producing
> | documentation.
>
> How much code would it break (probably lots, and someone should write a
> utility to find out) if ``vars'' declarations local to a procedure
> invented a *new* permanent variable which it then dlocalised? Then the
> intuition ``"vars" are local to a procedure, aren't they?'' would be
> more accurately reflected.
>
>
> Regards, | Applicants must also have extensive knowledge of Unix, | MIT
> Kers. | although they should have sufficiently good programming | job
> | taste to not consider this an achievement. | ad.
--
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs )
School of Computer Science, The University of Birmingham, B15 2TT, England
EMAIL A.Sloman@cs.bham.ac.uk
Phone: +44-121-414-4775 (Sec 3711) Fax: +44-121-414-4281
|