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

thp@cs.ucr.edu writes:
|> 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.


It is, and it has been done commercially for decades. The Numerical
Algorithms Group (NAG) has some mature technology and considerable
experience. Take a look at www.nag.co.uk or www.nag.com and look for
the NAGWare tools - and, if VERY interested, contact them and ask
about what they use internally as well.


Yes, they were heavily involved in the Toolpack project, and both fed
technology into that and used the results as a basis. For reasons
that we have gone into before, the above is feasible for Fortran and
"software engineering" C but nigh-on impossible for general C. That
is the experience of other organisations, too.


I have seen editors that have used this approach, and some have
certainly been produced commercially. Syntactic highlighting is old
technology, but I haven't seen this approach used to its full
potential. You could easily ask to highlight every statement that
could change a set of global data areas OR call another function that
might do so, for example. I have often wanted that ....


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679

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