In article <k0ji8t$sn...@newsreader4.netcologne.de>,
Thomas Koenig <tkoe...@netcologne.de> writes:
> Of course, there's the classic
> DO I = 1.100
> PRINT *,I
> 100 CONTINUE
> which doesn't do what you expect at first glance.
> IMPLICIT NONE
> would catch it, and also
> IMPLICIT CHARACTER*1 (A-Z)
Funny, it would do exactly what I expect. But then, I know Fortran
and therefore know exactly what it is going to do. :-)
-- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
> >Even if the
> > editor might help you find the problems in such code, revising large
> > codes can be a major problem in environments where any revision
> > necessitates revalidation. (In one project I worked on, revalidating
> > the flight software costs about a million dollars).
> Yes, regression testing is costly (not to mention tedious and time
> >If one works only
> > on programs that are of "modest" size and on which you are freely
> > allowed to do global edits, one is likely to have trouble
> > appreciating the environments where it is a big deal.
> Robin, I have worked in such environments. One site I worked on had a COBOL
> codebase of 60 million LOC (spread around 14 countries, but maintained from
> one location). At the peak of our COBOL usage, PRIMA's Codebase was still
> well under a million lines (today it is around 20,000 and decreasing), so
> please don't think I don't understand the implications.
> How "big a deal" it is will be determined by the site culture and approach.
> A site where global edits are forbidden would be a worry. To me that conveys
> lack of confidence in the people who are doing the maintenance. (They need
> all the help they can get...restricting their use of tools and techniques
> doesn't seem like a good thing to me, but again, it depends on the site
> culture. You mentioned Flight software and I would agree that any software
> where people's lives could be at stake requires more intense control than
> might normally be required.)
> I would want a Data Dictionary implemented on such a site and I would want
> oto be able to ensure that every use of every dataname was documented,
> cross-referenceable, and available as part of a generated data flow
> analysis. That makes global editing a lot less intimidating.
> >Sure, it is
> > easy enough for one's own personal programs. I've done it with some
> > of mine just because I preferred to avoid the confusion of a name
> > conflict with a newly added intrinsic, even though my code could have
> > continued working without the change. (SUM is certainly a variable
> > name I used to use fairly often; there are others as well.)
> Now consider it from the point of view of the compiler writer.
> If there are NO reserved words how would you implement a language?
FORTRAN did not have reserved words (and still does not).
PL/I has no reserved words, and has a larger "vocabulary" than COBOL.
On Tuesday, 31 July 2012 08:09:21 UTC+10, glen herrmannsfeldt wrote:
> In comp.lang.fortran Kerry Liles <k......@gmail.com> wrote:
> > No reserved words? It has been a long time since I used Fortran, but I
> > rather doubt:
> > DO DO=1 TO 10
> > would work would it?
> Legal assignment in fixed-form (where blanks aren't significant).
> (and no IMPLICIT NONE, or DODO is otherwise declared).
> There is also that old favorite assignment
> DO 1 I=1.10
> and you can write your DO loops (again, for fixed form):
> print *,do
Just because it's legal in fixed source form doesn't mean that
you have to use it.
Fixed source form is prone to letting errors slip though undetected.
Free source form doesn't admit such an error.
Nor would it admit the earlier error (though it would it the DO
statement were written
DO1I = 1.10
in which case IMPLICIT NONE would probably catch it.)
But why use such an obsolete form anyway?
DO I = 1.10
would be detected as an error in free source form.