formatted reading: real format without dot

[Richard E Maine]

On May 15, 2006, at 12:49 AM, Manfred Schwarb wrote:
   [about the nonstandard F4 format without a decimal point]

> Well, I don't want to promote such usage ...
> I just think that gfortran should ease transition for g77 users...

It isn't my call, but I'll throw in my two cents.

</rant>

If gfortran does decide to support the form, don't fool yourself  
about the result. It *WILL* promote the usage. I'd guess that g77 had  
it in order to ease transition,etc.

Of course, this is just a restatement of my personal opinion that  
gfortran accepts too many nonstandard practices in the name of  
compatibilty with various compilers, including g77. Yes, there are  
costs to accepting them.

Of course, there are the obvious costs of documenting, implementing,  
and maintaining them. These costs are almost always hugely  
underestimated. For a start, people seem to miss the parts about  
documentation and maintenance. Unless I have missed it somewhere,  
documentation of gfortran's extensions is already severely  
shortchanged. Is there anywhere even a comprehensive list of  
gfortran's extensions, much less a precise definition of the exact  
details of each one? The source code does not count. In my view, this  
lack is a huge deferred cost. If I were evaluating an investment  
property with such a large deferred maintenance, it would pretty much  
rule out the purchase. Are people who advocate extensions giving even  
token consideration of documentation requirements? The evidence I see  
would suggest not.

I see a short list in the docs wiki. If that list is actually  
anywhere near complete, then I am obviously way off base on this  
whole question. In that case, please ignore my whole posting as  
uninformed ranting. I could have sworn I have heard discussions of  
numerous extensions beyond that short list - like at least an order  
of magnitude more.

Then there are the potentials for conflicts with other features and  
extensions. The lack of comprehensive documentation exacerbates this  
problem. When looking at some *OTHER* feature, how do you know what  
it will break if you don't even know what there is to potentially be  
broken? Language extensions can interact in ways that make complexity  
grow far worse than linearly, as each new extension has more things  
that it might interact with.

I consider the question "why not?" to be indicative of an  
inadequately cautious attitude towards extensions. Or perhaps, it is  
just that my attitude is overly cautious. So let me state it more  
neutrally: I consider the question to be indicative of an attitude  
that differs greatly from mine. Sure there are some extensions that  
are a good idea - I agree with that, and I think almost everyone does  
to some degree. But I think that each extension needs to be carefully  
considered and justified. And by justified, I mean more than just  
stating that some existing code uses it, since if that is the  
criterion, you will end up with an unworkable mess of every extension  
ever used in any compiler, including extensions that conflict with  
each other. At the least, I'd expect a justification that was based  
solely on existing code base to include an estimate of how much  
existing code uses it, which other compilers do and don't support it,  
how difficult code conversion would be, the importance of the codes,  
etc. And I'd expect those estimates to be realistic - I've seen  
people in J3 who overstated the importance of absolutely every  
proposal they submitted as being critical to the continued survival  
of Fortran - the exageration is counterproductive in that it tends to  
make me doubt their judgement of everything.

</end rant>

-- 
Richard Maine                |  Good judgment comes from experience;
Richard.Maine@nasa.gov       |  experience comes from bad judgment.
                             |        -- Mark Twain