From: Koen Holtman (koen@hep.caltech.edu)
Date: Wed Sep 27 2000 - 14:45:34 PDT
A mathematics of programming thread. Oh what fun...
On Wed, 27 Sep 2000, Tony Finch wrote:
[....]
> Since most languages in use today have a specification like
> a dogs dinner, compilers for those languages have a fairly limited
> understanding of the code they are compiling (and frequently any
> possibility of useful understanding is scuppered by the
> specification).
Um.. I have to disagree here. A very bulky language specification is
a hurdle, but not an insurmountable one, to a compiler being able to
analyse the code it compiles for bugs, deficiencies, or optimisation
opportunities.
Take C, for example. The single biggest problem here, for a compiler
analysing the code for possible optimisations, is potentially
unconstrained pointers. For example, a piece of code like
*p=5;
*q=f(*r);
could be optimised in some cases, when converting to machine code, by for
example moving the assignment *p=5 after the code that does *q=f(*r); .
But that is only legal _if p,q,and r point to different things_. So to do
this code-resuffle while preserving C semantics, the compiler will first
have to prove by some analysis that all pointers point to different stuff.
But that is usually impossible, especially if some of the pointers were
function arguments.
About the same is true, of course, if you change the pointer assignments
above to inline method invocations for objects you have pointers to (or
handles of).
Of course there are some people in CS who would argue that a language
definition that includes pointers or handles is inherently ugly etc. And
insofar as their sense of beauty is formed by their intuition of what is
mathematically tractable they would be exacly right.
What is really needed to improve compilation and bug finding, if you don't
want to thow away pointers, object handles, or those pesky recursive
datastructures, is language constructs which allow the programmer to
express `these two pointers/handles/etc that were passed into this
function are guaranteed to point to different storage', and also `this
object is owned by that object and the ownership relation is nowhere
cyclic'.
State-of-the-art compile time analysis and bug
> spotting relies on languages with precise definitions and
> sophisticated type systems, which tend to discourage less
> mathematically-inclined programmers.
I'd say Java has about as precise a definition as you can get, possibly
also a sophisticated type system. Don't see too many people discouraged
by that...
Koen.
This archive was generated by hypermail 2b29 : Wed Sep 27 2000 - 14:49:08 PDT