Re: Uninitialized "out" parameters

[ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)]

bobduff@world.std.com (Robert A Duff) writes:
>Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>>Bob Duff is the last person I would have expected to argue against static
>>checks.

>I'm not sure why it surprises you -- after all, I had a hand in writing
>an RM that has more run-time checks than you can shake a stick at.  ;-)

Because your postings have given me reason to believe you are a very
competent programmer (Robert Dewar's postings have given me the same
impression of him, even if we don't see eye-to-eye).

>Consider the case of divide-by-zero.  We could easily catch all
>divides-by-zero at compile time, if we're willing to be overly
>conservative.  However, this would make the language a lot less useful.

You are telling this to a programmer who is in the habit of making
sure that every integer division involves a divisor declared to be
Positive rather than Integer, and thinks that this is one good reason
for using Ada instead of C.

Floating point divide by zero, that's another matter.

>>If I can get a compile-time error (when it is provable that an uninitialised
>>variable will be used) or warning (when it is not provable that it won't),
>>why *not*? ...

>I certainly agree with the first part (just like I want the compiler to
>complain if it *knows* I'm going to divide by zero).  But the second
>part is questionable.  It means I'm going to get a lot of spurious
>warnings, since my programs typically contain lots of pointers to
>heap-allocated records, and it's not feasible for a compiler to do a
>very good job for that kind of data.

It _isn't_?  But I've seen lclint *DO* it!  And so does Mercury.
It may or may not be feasible for an Ada95 compiler to do a good job;
I have never written an Ada95 compiler and can't presume to judge
what is or is not feasible for that.  What I *can* say is that it isn't
just "feasible" in principle, there are systems that DO it.

Of course this means having a richer type system, in which it is possible
to express "X is a non-null pointer to a record with an initialised Y
field, an initialised Z field, and an uninitialised W field".  To a first
approximation, the Mercury type/mode system does exactly that.  It's even
possible for such a type system to keep track of whether pointers are
unique or not (Clean does this, it's in the Mercury type system, and the
lclint checker does a practically useful job of it for C).

I wish people wouldn't keep telling me that it isn't feasible to do
what several of the tools I use *DO* do.  This is not rocket science!

>Note that in this case, run-time checks will probably find more bugs
>than compile-time checks.

I am not arguing *against* run-time checks.
I am arguing against run-time checks as a substitute for compile-time
checks.
I would be delighted to have both.
If I have to put up with only one, I will take the compile time checks;
I do not want to impose the run-time burdens that Robert Dewar has
listed on other programmers.

>Anyway, I don't believe compile time checking is always better than run
>time checking.  It's a trade-off, and the language designer has to
>consider the details of each case.  The compiler writer, too, for
>deciding what warnings to produce.

Compile time checking of property Z, in a language that permits it,
    - forbids some meaningful programs
    - ensures that a class of errors is not present
    - has lower run-time penalties, and because the compiler knows
      more, may permit the generation of better code
Run time checking of property Z, in an implementation that permits it,
    - places fewer restrictions on source programs
    - ensures that a class of errors will not be *executed* without warning
    - has higher run-time penalties.

You can substitute the property of your choice for Z.
When Z = "type correctness", it's widely used as a stick to beat Lisp with.
Existing systems show that the analogy holds for
Z = initialised/not and Z = null/non-null unique/shared pointer
in languages designed with such checks in mind.

How much of this could be carried over to a language like Ada that was
*not* designed with such checks in mind is a practical issue on which
Robert Dewar and others can speak with authority and I cannot.  All I
can say is that lclint shows that you can do a lot more than you might
think.

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.