Re: Ada vs Fortran for scientific applications

["Alex R. Mosteo" <devnull@mailinator.com>]

Tom Linden wrote:

> On Tue, 11 Jul 2006 08:02:47 -0700, <adaworks@sbcglobal.net> wrote:
> 
>>
>> "Tom Linden" <tom@kednos.com> wrote in message
>> news:op.tci16qgszgicya@hyrrokkin...
>> On Mon, 10 Jul 2006 23:46:45 -0700, <adaworks@sbcglobal.net> wrote:
>>
>>>
>>> "robin" <robin_v@bigpond.com> wrote in message
>>> news:z9Dsg.2740$tE5.2374@news-server.bigpond.net.au...
>>>>
>>>> Compilers can check for uninitialized variables during compilation.
>>>>
>>> True.  In fact, Ada compilers issue a warning for any variable
>>> that is used before a value is assigned to it.    If a parameter is
>>> included in a method (function/procedure/subroutine) and never
>>> referenced, a warning is issued.    Sometimes the pragma
>>> Normalize_Scalars is useful.   Often, the correct design is to
>>> leave variables uninitialized until they are used so an exception
>>> can be raised.   However, since the compiler will emit a warning
>>> about variables that have never been assigned a value in an algorithm
>>> that tries to use it, no harm is really done since the careful
>>> programmer
>>> will not release a program with warnings in it.
>>
>> TL>In general, this is not possible, and it is somewhat silly to have the
>> TL>compiler issue such messages, because on the average it will be
>> TL>wrong as often as  it is right.  This can not be done at compile-time
>> TL>but must be done at run-time and it requires the compiler to
>> TL>generate a lot of machinery to produce such mediocre messages.
>> TL>Wht we did in PL/I was to produce in the cross-reference
>> TL>listing information on where a variable was referenced or
>> TL>assigned, but  this was also somewhat incomplete because
>> TL>it requires a further analysis of  aliasing.  My view is that it is
>> TL>of dubious value.
>> TL>
>>
>> It  might be of dubious value in PL/I, but it is quite helpful
>> in Ada.  These warnings often help with better structuring of a
>> program.   In a large, complex program, they prevent errors that
>> result from simple little oversights we all make in the normal
>> course of programming.
>>
>> These kinds of warnings extend to methods declared, but never
>> invoked.   For example, in the sample code in the earlier post,
>> if I had never used Ada.Integer_Text_IO in my program, the
>> compiler would have informed me that I had a package in
>> scope that I never used.   I have never known the compiler
>> to issue a message that was wrong.   On the other hand,
>> it is a warning, not a fatal error because I really might want
>> to use that artifact in a future iteration of my development.
>> When I do use it, the warning goes away.   I personally
>> find this very helpful.   Others may find it annoying.    In
>> the long run, it is a good feature when developing
>> safety-critical software where extraneous code is not a
>> good thing.
> 
> My comments were not restricted to PL/I, but apply generally to
> any compiler, and specifically Ada was intended.  Since I had put
> in the scaffolding for producing the info in cross reference listings
> I also played with generating precisely the sort of warnings that you
> refer to, but found it generated too much "clutter" of questionable
> value.  That was my view, FWIW

I have to disagree. Warnings for unused entities have helped me in many
instances. Forgotten calls, forgotten updates to loop control variables are
the obvious examples. These warnings don't usually reveal subtle bugs that
would go unnoticed, but evident errors that would be caught in testing, but
this undoubtedly reduces wasted time. In my experience, 90% of these
warnings did correspond to a real bug and the rest were due to removed
code, so the unused entities could be removed/commented as well, which I
prefer.

In particular, I know the precise warnings Richard is referring to (I guess
we use the same compiler), and they have never been clutter for me. I can't
imagine code generating lots of these warnings not being a maintenance
nightmare.

In general, if compiler warnings are well done, which basically means no
false positives that lead to ignoring/disabling them, are another excellent
tool for better development. My Ada compiler has never disappointed me in
this regard.