Aaron writes:
| 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 ????
Good catch.
It's true that I don't use the matcher; I've rarely found anywhere where
it would do anything useful for me. This may just reflect the kind of
programs I write, or the way I want to write them.
[I must revisit my recent Magic-cards-nad-rulings-to-html converter;
the matcher might have been useful there ...]
But my functional programming background would drive me to use a matcher
that didn't update any (non-private) variables at all; it would *deliver
a result*. This seems more natural to me (I realise this says a lot
about my background and style, rather than being a Law of Programming).
Then the results of a match could be used in expressions without having
to introduce unnecessary variables.
| 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,
Is *that* why they do it? I find it makes the code incomprehensible.
| and also makes it easy to check which variables are and are not used
| in the procedure.
Why would one want to check? Assuming that they're genuine locals
(which, I think, will cover almost all the cases), then they're used if
they're used, and not if they're not, and the outside would doesn't
care.
| On the other
| hand I find myself increasingly writing at arbitrary locations in
| procedures things like
|
| lvars xxx = fff(ppp,qqq,rrr....);
Well, of course. I've being doing that for years.
| 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.
That depends on what you think is happening. Something more complex *is*
happening each time round the loop; a variable comes into being, and is
initialised (or rather, a value is computed and named).
| 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.
I think the problem here is a Pop problem, that loops are not properly
scoped, so that variables introduced in a loop are visible afterwards.
If they were not, it would be clear that ``the'' variable *did* appear
and disappear each time round, and there'd be nothing wrong with that.
| 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?
For ``vars'' this is more the case, although one can claim that the
``vars'' does one thing and the ``='' another. In any case, doing
several things at once is hardly a potent criticism.
Regards, | "You're better off not dreaming of the things to come;
Kers. | Dreams are always ending far too soon." - Caravan.
|