[Info-vax] Fortran

[Dave Froble]

On 12/5/2018 8:25 AM, Simon Clubley wrote:
> On 2018-12-05, abrsvc <dansabrservices at yahoo.com> wrote:
>> On Wednesday, December 5, 2018 at 4:32:39 AM UTC-5, Dave Froble wrote:
>>> On 12/5/2018 3:26 AM, Simon Clubley wrote:
>>>>
>>>> They were removed because it is a concept which results in both
>>>> hard to read and hard to maintain code and which was replaced by
>>>> a safer option decades ago.
>>>>
>>>> Fortran has had ideas which seemed good at the time but which have
>>>> not stood the test of time. The other one which comes immediately
>>>> to mind are common blocks whose definitions are repeated in more
>>>> than one place.
>>>>
>>>
>>> The question remains, was it necessary?
>>>
>
> Yes.
>
>>> If the compiler could have continued to support the "hard to read and
>>> maintain code", and there was no reason to remove the capability, then
>>> that should not have been done.
>>>
>
> And what about newly written compilers ?
>
> Should they continue to support an obsolete and dangerous construct
> when there's a safer replacement ?
>
> This is no different from requiring /standard=vaxc to build VAX C code
> in DEC C. Should every new compiler have a /standard=vaxc option added
> to it or should the user's code be changed to use modern constructs ?
>
> If John is reading this, please, please, please tell me you are _NOT_
> going to add a /standard=vaxc option to Clang. :-)
>
>>> Causing others to do some work, which would not have been necessary, is
>>> not a good thing.  Causing others to re-write usable code, because some
>>> don't like it, is arrogance carried to the extreme.
>>>
>>
>> The one that caused the most pain was the loss of the octal constant support.  While trivial to change, the decades old modules that continue to provide the functions required had to be changed only to specify the value in a different way.  Why?  It seems to me that supporting this was not a major problem.  It is water under the bridge now of course, but many man-hours were spent to make this change.
>>
>
> Removing octal constant support was a bit strange unless there's
> something I am not understanding. Like you, I don't really see any
> reason why it could not have been left in place. This is different
> from the removal of Hollerith support where the removal of Hollerith
> support brings distinct safety benefits.
>
> Simon.
>

There is a difference between making things better, and removing things 
because someone "doesn't like it".

No, I would not implement things such as "/standard=vaxc" in new 
compilers, however, I would not remove it from where it already exists.

Consider, Dave doesn't like C, therefore all computers will no longer 
support this language.  Extreme, yes, but, the same concept, right?  All 
I'm trying to say is, if it does not have to be removed, then don't do 
so, because you might be causing someone else grief.  If it does have to 
be removed to make needed improvements, then do so.

I seem to recall in the past some maintainer of some flavor of Linux 
removing modem support, or something similar, because that person no 
longer used modems, and caused grief for some who upgraded their OS. 
Same basic concept.  Don't break someone else's code without very good 
reason.


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486