Re: Pointers to "why C behaves like that ?"

Dr A. N. Walker <anw@merlot.uucp> wrote:
+ Charles Bryant <r368714668.ch@chch.demon.co.uk> wrote:
+><thp@cs.ucr.edu> wrote:
+>> Agreed. It's as though the compiler is continually giving an
+>> impromptu quizzes to the programmer, [...]
+>However the compiler is acting on behalf of all the future maintenance
+>programmers who would be quizzing the original programmer if only they
+>could travel back in time.
+
+ I think there is a danger of assuming that all programs fit
+ one familiar model. Your environment may be one in which the needs of
+ maintenance programmers are important. Mine is not. It used to be;
+ especially from the point of view that my maintenance programmer could
+ be me, six months down the line when I've forgotten how the code
+ worked. But these days, my programs are usually small run-once
+ thinggies, or small do-some-simple-task thinggies, and they will
+ never be "maintained" in the way that an operating system is.
+ Increasingly, my big "programs" in fact consist of bundles of shell
+ scripts with occasional diddy-C stuff mixed in.


This difference of opinion is reminds me of the recurring question of
whether it is better to pass variables by pointer or by reference.
The argument goes that, while the original programmer might prefer to
write "increment(n)" rather than "increment(&n)", the latter form
tells maintenance programmers, and perhaps the even original
programmer, that the call to increment can change the value of n.
Similar arguments were also made in favor of the Hungarian naming
convention, where names of variables were mangled a bit to indicate
their types.


It should be possible, once a program has been parsed into an abstract
syntax tree, to present various annotated views of that database,
regardless of how the original programmer specified the program:
    - adding Hungarian prefixes,
    - adding types etc for implicitly declared variables,
    - displaying keywords in distinctive colors or fonts,
    - adding helpful comments, e.g., "increment(/*changes*/ n)"
    - and so forth.
I assume that some static analysis tools might already provide
such services. If so, then some of the arguments against implicity
typing evaporate.


There is still the argument that a typo might create a new variable
instead of a syntax error, e.g.:


                            fumds = funds + income;


but, unless the typo is repeated, e.g.:


                            funds = fumds - expenditures;


the typo will produce an unused-variable warning. To insure against
such repeated typos, the language can require a keyword to accompany
the introduction of a new variable, e.g.:


                            let profit = income - expenditures;


In such a case the first typo above would produce a syntax error.


Tom Payne

Return to the comp.compilers page.
Search the comp.compilers archives again.