[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Dec 1 10:55:35 1995 
Subject:Re: reporting pop bugs (and pvars) 
From:Chris Dollin 
Volume-ID:951201.07 

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.