WHy Fortran SELECT statment has an extra CASE at the top?

[Nasser M. Abbasi]

I am newbie and learning a bit of Fortran, and noticed that Fortran
SELECT is kind'a strange. Why the duplicate use of CASE at the top
and also in each branch?

------------------------------
SELECT CASE(n)
CASE(v1)
CALL do_something()
CASE(v2)
CALL do_something_else()
END SELECT
-----------------------------

That extra CASE at the top looks superficial to me. Why not just

------------------------------------
SELECT n
CASE(v1)
CALL do_something()
CASE(v2)
CALL do_something_else()
END SELECT
--------------------------------

The above is how it is in many languages I've seen. Here is Ada:

----------------------
CASE n is
WHEN v1 => ....
WHEN v2 => ....
END CASE;
----------------------

in C:
------------------
switch (n)
{
case v1:
....
case v2:
....
}
------------------------
The point is, that extra CASE at the top seems to be out of place.

Any reason for it and why it is needed at top?

Just wondering, that is all.
Thanks,
--Nasser

[dpb]

On 7/24/2012 5:07 AM, Nasser M. Abbasi wrote:
> I am newbie and learning a bit of Fortran, and noticed that Fortran
> SELECT is kind'a strange. Why the duplicate use of CASE at the top
> and also in each branch?

...

> Any reason for it and why it is needed at top?

...

Short answer is "Because..." :)

But, it isn't that there's a duplicate CASE, the statement is "SELECT
CASE" and that's what the committee chose to name it. Again, what
another language may have done doesn't have any bearing on Fortran.

Fortran is rather unique among languages in that parsing is only
dependent on context--there are not reserved words that are reserved in
all contexts and in fixed source form even spaces aren't significant.

--

[mecej4]

On 7/24/2012 5:07 AM, Nasser M. Abbasi wrote:

> I am newbie and learning a bit of Fortran, and noticed that Fortran
> SELECT is kind'a strange. Why the duplicate use of CASE at the top
> and also in each branch?
>

............

> The point is, that extra CASE at the top seems to be out of place.
>
> Any reason for it and why it is needed at top?
>

Many programming languages provide the user and/or the compiler some
"syntactic sugar". Look up the phrase.

-- mecej4

[Gordon Sande]

Or maybe someone was looking ahead, or was lucky, to the SELECT TYPE statement.

[Thomas Jahns]

On 07/24/2012 03:05 PM, dpb wrote:
> Fortran is rather unique among languages in that parsing is only
> dependent on context--there are not reserved words that are reserved in
> all contexts and in fixed source form even spaces aren't significant.

I wish this was true for enough implementations but I'd never count on this.
After being bitten a few times I'd suggest to stay clear of language keywords
and intrinsic names. I can tell that it results in some interesting bugs if a
variable is named imod.

Regards, Thomas

[robin....@gmail.com]

On Tuesday, 24 July 2012 23:05:36 UTC+10, dpb wrote:
> On 7/24/2012 5:07 AM, Nasser M. Abbasi wrote:

> > I am newbie and learning a bit of Fortran, and noticed that Fortran
> > SELECT is kind'a strange. Why the duplicate use of CASE at the top
> > and also in each branch?
> ...
>
> > Any reason for it and why it is needed at top?
> ...
>
> Short answer is "Because..." :)
>
> But, it isn't that there's a duplicate CASE, the statement is "SELECT
> CASE" and that's what the committee chose to name it. Again, what
> another language may have done doesn't have any bearing on Fortran.

>
> Fortran is rather unique among languages in that parsing is only
> dependent on context

Fortran is not unique. PL/I also has no reserved words.

>--there are not reserved words that are reserved in
> all contexts and in fixed source form even spaces aren't significant.

One of the worst "features" of the language.

[robin....@gmail.com]

On Tuesday, 24 July 2012 20:07:55 UTC+10, Nasser M. Abbasi wrote:
> I am newbie and learning a bit of Fortran, and noticed that Fortran
> SELECT is kind'a strange. Why the duplicate use of CASE at the top
> and also in each branch?
>
> ------------------------------
> SELECT CASE(n)
> CASE(v1)
> CALL do_something()
> CASE(v2)
> CALL do_something_else()
> END SELECT
> -----------------------------
>
> That extra CASE at the top looks superficial to me. Why not just
>
> ------------------------------------
> SELECT n

Because
SELECT CASE (n)
is better english.

As for CASE (v1) etc, the keyword makes it clear that the line
introduces one of the selections.

The keyword also makes it easier for the compiler to recognize.

[Richard Maine]

And as the OP contrasted with Ada syntax, I might note that I personally
recall finding Ada's syntax to be fairly heavy for my taste on such
syntactic sugar in some places. They just happen to be different places
that Fortran's. For example, I seem to recall what struck me as a
superfluous insertion of "is" in at least one place in Ada. Admitedly,
it was a long time ago that I got this impression of Ada. I guess it
must have been in the very early 1990's, when I was debating what
language to do a major new project in. I ended up deciding on f90, but I
recall looking at Ada as one possible alternative. My tastes have
changed enough since then that I suppose I might well find the wordiness
more to my liking now.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[Phillip Helbig---undress to reply]

In article <juls5r$k8n$1...@speranza.aioe.org>, "Nasser M. Abbasi"

<n...@12000.org> writes:

> I am newbie and learning a bit of Fortran, and noticed that Fortran
> SELECT is kind'a strange. Why the duplicate use of CASE at the top
> and also in each branch?

Interesting question.

> SELECT CASE(n)
> CASE(v1)
> CALL do_something()
> CASE(v2)
> CALL do_something_else()
> END SELECT

I do like the SELECT as an "introductory" statement, with each branch
having its own CASE. With IF, the first IF block both introduces the
construct and the first block. If one indents ELSE IF at the same level
as IF (i.e. not at all), then things other than the beginning and end of
the block are indented. If not, then it is different than the first
block.

[dpb]

On 7/24/2012 10:45 AM, robin....@gmail.com wrote:
> On Tuesday, 24 July 2012 23:05:36 UTC+10, dpb wrote:

...

>> Fortran is rather unique ...

>
> Fortran is not unique. PL/I also has no reserved words.
>

...

_NOT_ "unique" but "rather unique". There _IS_ a difference and it
_WAS_ deliberate.


OTOH, how many are there that _do_ have reserved words?

--

[John Harper]

Pascal and at least one Algol 60 dialect do. We had a machine many years ago
in which alpha (or was it ALPHA?) could not be the name of a variable in an
Algol program: it was used like Fortran's statement keyword CHARACTER.

--
John Harper

[dpb]

Well, there certainly are the two front-runners, C & C++ and then the
lookalikes.

I couldn't find a BASIC Standard document to know what actually was
standardized; Dartmouth BASIC had keywords but spaces were not
significant. But, it only allowed variable names of either a letter or
a letter and a single digit so naming a variable a keyword wasn't
possible. I'm not sure how it went when the Standard was approved--I'd
_presume_ keywords are reserved but I don't know that.

--

[robin....@gmail.com]

On Wednesday, 25 July 2012 03:31:38 UTC+10, dpb wrote:
> On 7/24/2012 10:45 AM, rrrrrrr...@gmail.com wrote:

> &gt; On Tuesday, 24 July 2012 23:05:36 UTC+10, dpb wrote:
> ...
>
> >> Fortran is rather unique ...
>
> > Fortran is not unique. PL/I also has no reserved words.
>
> ...
>
> _NOT_ "unique" but "rather unique". There _IS_ a difference and it
> _WAS_ deliberate.

Algol 60 doesn't have reserved words, nor did GEORGE.
Many of the early languages (pre mid-1950s) didn't have
reserved words.

[dpb]

On 7/24/2012 8:15 PM, robin....@gmail.com wrote:
> On Wednesday, 25 July 2012 03:31:38 UTC+10, dpb wrote:
...

>> _NOT_ "unique" but "rather unique". There _IS_ a difference and it
>> _WAS_ deliberate.
>
> Algol 60 doesn't have reserved words, nor did GEORGE.

What about FRED, or TOM, or even HARRY? :)

Sad to say, I've never heard of poor GEORGE the language, only a few
kings and presidents.

> Many of the early languages (pre mid-1950s) didn't have
> reserved words.

Well, at least a fair number do now...and it seems more significant to
compare to some of the more popular languages of the day.

--

[Robin Vowels]

On Jul 25, 12:03 pm, dpb <n...@non.net> wrote:

> On 7/24/2012 8:15 PM, rrrr...@gmail.com wrote:> On Wednesday, 25 July 2012 03:31:38 UTC+10, dpb  wrote:
>
> > Algol 60 doesn't have reserved words, nor did GEORGE.
>

> > Many of the early languages (pre mid-1950s) didn't have
> > reserved words.
>
> Well, at least a fair number do now...and it seems more significant to
> compare to some of the more popular languages of the day.

Compiler writers/designers of today are lazy.
It's certainly easier to treat language words as reserved words.
But, significantly, they avoided keywords in FORTRAN.
And, no doubt aggrieved at the plethora of reserved words in COBOL --
the bane of any programmer -- went out of their way to avoid them
when designing PL/I. That was a commendable feat, for PL/I has
many more keywords than FORTRAN then had.

The advantage of a language that does not have reserved words
is that new features can be added without trashing older programs
that might have used new words that are introduced.

[glen herrmannsfeldt]

In comp.lang.fortran Robin Vowels <robin....@gmail.com> wrote:

(snip regarding reserved words)

> Compiler writers/designers of today are lazy.
> It's certainly easier to treat language words as reserved words.

Well, also it avoids some ambiguities that otherwise occur.

Allowing subroutine/function calls without a special (not
necessarily reserved) keyword avoids many.

> But, significantly, they avoided keywords in FORTRAN.
> And, no doubt aggrieved at the plethora of reserved words in COBOL --
> the bane of any programmer -- went out of their way to avoid them
> when designing PL/I. That was a commendable feat, for PL/I has
> many more keywords than FORTRAN then had.

Note that in C, any identifier is a legal, but useless,
statement. Without reserved words, that would disqualify
any single (no expression, etc.) keyword statement.

> The advantage of a language that does not have reserved words
> is that new features can be added without trashing older programs
> that might have used new words that are introduced.

That, to me, is a big one. Among others, newer C versions
have done some strange things to avoid problems with new words.

-- glen

[dpb]

On 7/25/2012 1:14 AM, Robin Vowels wrote:
...

> Compiler writers/designers of today are lazy.

...

I'm _sure_ that's how K&R think of themselves, indeed... :)

--

[Peter Flass]

On 7/25/2012 2:14 AM, Robin Vowels wrote:
> On Jul 25, 12:03 pm, dpb <n...@non.net> wrote:
>> On 7/24/2012 8:15 PM, rrrr...@gmail.com wrote:> On Wednesday, 25 July 2012 03:31:38 UTC+10, dpb wrote:
>>
>>> Algol 60 doesn't have reserved words, nor did GEORGE.
>>
>>> Many of the early languages (pre mid-1950s) didn't have
>>> reserved words.
>>
>> Well, at least a fair number do now...and it seems more significant to
>> compare to some of the more popular languages of the day.
>
> Compiler writers/designers of today are lazy.
> It's certainly easier to treat language words as reserved words.

Lazy is a good word. There are only a very few cases where lack of
reserved words is a parsing problem when writing a PL/I compiler.
Everyone wails and moans about what a problem it is, but I think that's
just because the dumb tools they're using can't hack it, and they're not
willing to look beyond them.


--
Pete

[glen herrmannsfeldt]

In comp.lang.fortran Peter Flass <Peter...@yahoo.com> wrote:

(snip, someone wrote)

>> Compiler writers/designers of today are lazy.
>> It's certainly easier to treat language words as reserved words.

> Lazy is a good word. There are only a very few cases where lack of
> reserved words is a parsing problem when writing a PL/I compiler.
> Everyone wails and moans about what a problem it is, but I think that's
> just because the dumb tools they're using can't hack it, and they're not
> willing to look beyond them.

C, on the other hand, has many ambiguities if you try to do it
without reserved words. This is especially true with the null statement.

if(1);
while(x);
return;

(Probably more, but I don't have a list of statements nearby.)

If Fortran and PL/I didn't have a CALL statement, but called
subroutines C style, there would be some ambiguities

READ(3,1)
WRITE(4,2)
FORMAT(I1)

in Fortran, many others in PL/I.

-- glen

[Shmuel Metz]

In <juoibr$ru1$1...@speranza.aioe.org>, on 07/25/2012

at 10:38 AM, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:

>Well, also it avoids some ambiguities that otherwise occur.

I'm not aware of any ambiguities in PL/I due to the lack of reserved
words. Any amgiguities in C are irrelevant to PL/I.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Nasser M. Abbasi]

Having reserved words in a computer language is a Good Thing (TM).
Not having reserved words in a computer language is not a good thing.

--Nasser

[Richard Maine]

Nasser M. Abbasi <n...@12000.org> wrote:

> Having reserved words in a computer language is a Good Thing (TM).
> Not having reserved words in a computer language is not a good thing.

I bet you would think differently if you had ever been responsible for
maintaining large existing codes. As has been mentioned elsethread,
reserved words have the problem that whenever you add new ones you
invalidate previously valid working programs. That kind of thing is a
*BIG* deal in the so-called real world. Do that kind of thing to people
very often and the problem will "solve itself" because there won't be
any more large existing applications to worry about; they will have
moved to other languages that are more stable in that regard.

[glen herrmannsfeldt]

In comp.lang.fortran Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:

(snip, I wrote)

>>Well, also it avoids some ambiguities that otherwise occur.

> I'm not aware of any ambiguities in PL/I due to the lack of
> reserved words. Any amgiguities in C are irrelevant to PL/I.

If you make some other changes to PL/I, then you can easily
get ambiguities. There is, therefor, a tradeoff on not having
those features.

One feature of many other languages is the ability to call a
procedure without a special (not necessarily reserved) keyword
(CALL), and not in the context of assignment or other place where
an expression is allowed.

No reserved words, and convenient (CALL less) procedure calls
are both nice features, but easily cause ambiguities if combined.

-- glen

[Robin Vowels]

On Jul 26, 7:02 am, "Nasser M. Abbasi" <n...@12000.org> wrote:
> Having reserved words in a computer language is a Good Thing (TM).
> Not having reserved words in a computer language is not a good thing.

No it's not.

When new keywords are introduced into the language, reserved words
cause some existing programs to fail.

Not having reserved words means that an update to the language
will not affect existing programs.

Apart from that, there's the problem that in writing a new program,
or in modifying an existing one, a programmer will use one or more
reserved words inadvertently, resulting in wasted time. If there
were few reserved words, one could remember them all. Earlier
versions of COBOL had 300+ reserved words, and it was a pain to use
the language.

[John Levine]

>> I'm not aware of any ambiguities in PL/I due to the lack of
>> reserved words. Any amgiguities in C are irrelevant to PL/I.
>
>If you make some other changes to PL/I, then you can easily
>get ambiguities. There is, therefor, a tradeoff on not having
>those features.

Well, sure, but they didn't. PL/I syntax is unambiguous, even for
nonsense like this:

IF THEN = ELSE; THEN IF = THEN; ELSE IF = ELSE;

You can't tokenize it with a naive state machine, but I don't think
it's any worse than Fortran, which required arbitrary lookahead in a
statement to tell whether it was an assignment or not.

I gather the motivation was that they expected few programmers to know
all of PL/I, but rather to program in the Fortran-ish or Cobol-ish
subsets. They didn't want keywords for the parts a programmer didn't
know to bite them.

I learned PL/I from the reference manual, so I was somewhat familiar
with the whole language, and people told me I wrote some of the
strangest PL/I they ever saw.

R's,
John

--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

[Pete Dashwood]

I'm neutral over whether it is a "Good Thing" or not.

If you use a proper Editor with Intellisense (Visual Studio/Eclipse are just
2 very good ones...) you will NEVER use a reserved word improperly so that
argument carries no weight for me.

I can't imagine why anyone would need or want to remember reserved words...
I'm just thankful that my memory of VSAM return codes is at last starting to
fade... :-)

Currently, I have tools that do a considerable amount of analysis of COBOL
Source. The parser I wrote to do this recognises 630 COBOL reserved words...
(That probably still isn't enough for some implementations).

Pete.
--
"I used to write COBOL...now I can do anything."

[glen herrmannsfeldt]

In comp.lang.fortran John Levine <jo...@iecc.com> wrote:
>>> I'm not aware of any ambiguities in PL/I due to the lack of
>>> reserved words. Any amgiguities in C are irrelevant to PL/I.

>>If you make some other changes to PL/I, then you can easily
>>get ambiguities. There is, therefor, a tradeoff on not having
>>those features.

> Well, sure, but they didn't.

As mentioned later, one feature is the ability to CALL procedures
without a special keyword.

> PL/I syntax is unambiguous, even for
> nonsense like this:

> IF THEN = ELSE; THEN IF = THEN; ELSE IF = ELSE;

> You can't tokenize it with a naive state machine, but I don't think
> it's any worse than Fortran, which required arbitrary lookahead in a
> statement to tell whether it was an assignment or not.

That is pretty unusual. Still, there are some times when a
certain word is appropriate, and it seems wrong to be denied
it use.

> I gather the motivation was that they expected few programmers to know
> all of PL/I, but rather to program in the Fortran-ish or Cobol-ish
> subsets. They didn't want keywords for the parts a programmer didn't
> know to bite them.

I will guess that COBOL programmers after a while start using
non-words for variable names, even if there are any good words
left not on the list.

> I learned PL/I from the reference manual, so I was somewhat familiar
> with the whole language, and people told me I wrote some of the
> strangest PL/I they ever saw.

I learned Fortran from the IBM Language Reference, and I believe
PL/I, too. Well, I actually had a new copy of the Fortran manual,
but many later ones were recovered from the pile of old manuals
that others didn't want anymore.

After using PL/I (F), in high school we had the CALL/OS version
of PL/I, but I only had the (F) manuals. It didn't have all the
features, but after a while, I learned which ones it did have.

After reading the assembler output from the compilers, the source
for the OS/360 Fortran library, and some other assembler program,
and with the Assembler reference and Principles of Operation, I
started writing Assembler program.

-- glen

[John Levine]

>> I gather the motivation was that they expected few programmers to know
>> all of PL/I, but rather to program in the Fortran-ish or Cobol-ish
>> subsets. They didn't want keywords for the parts a programmer didn't
>> know to bite them.
>
>I will guess that COBOL programmers after a while start using
>non-words for variable names, even if there are any good words
>left not on the list.

I gather some places required that all variable names start with a
digit, or otherwise use syntax known not to occur in reserved words.
Everyone seems to agree that the vast list of reserved words is a
major problem in COBOL.

[Richard Maine]

Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:

> Robin Vowels wrote:

> > When new keywords are introduced into the language, reserved words
> > cause some existing programs to fail.

> If you use a proper Editor with Intellisense (Visual Studio/Eclipse are just
> 2 very good ones...) you will NEVER use a reserved word improperly so that
> argument carries no weight for me.

That might be so for limitted values of "never". It won't help the case
where you have existing code and have to deal with a newer version of
the language that adds new reserved words. 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). 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. 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.)

[Peter Flass]

On 7/26/2012 1:47 AM, John Levine wrote:
>>> I gather the motivation was that they expected few programmers to know
>>> all of PL/I, but rather to program in the Fortran-ish or Cobol-ish
>>> subsets. They didn't want keywords for the parts a programmer didn't
>>> know to bite them.
>>
>> I will guess that COBOL programmers after a while start using
>> non-words for variable names, even if there are any good words
>> left not on the list.
>
> I gather some places required that all variable names start with a
> digit, or otherwise use syntax known not to occur in reserved words.
> Everyone seems to agree that the vast list of reserved words is a
> major problem in COBOL.
>
> R's,
> John
>

I think I've seen the convention where, e.g. every field in
"PAYROLL-RECORD" would begin with "PR-", for example "PR-SALARY", and
stuff in WORKING-STORAGE would begin with "WS-". Identifiers couldn't
start with a digit (IIRC).

--
Pete

[Gordon Sande]

That the editor solves the problem also makes the assumption that the
editor's list of reserved words has been undated completely, accurrately
and instantly. More likely the list will have a few additions after several
users have complained as a result of being bitten. Just look at the F90
support in various editors.

Nice theory but. How does it go - "In theory practice and theory are the
same but in pratice theory and practice are not the same".

[Robin Vowels]

On Jul 26, 8:25 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> One feature of many other languages is the ability to call a
> procedure without a special (not necessarily reserved) keyword
> (CALL), and not in the context of assignment or other place where
> an expression is allowed.
>
> No reserved words, and convenient (CALL less) procedure calls
> are both nice features,

I don't see a "CALL Less" procedure call as a "feature".
CALL makes it absolutely clear to the reader (and to the compiler)
that a subroutine is being invoked.

Without it, the compiler has to look ahead to see whether the final
')' is followed by a semicolon, before it can do anything with it.

It's not an imposition to type five characters, namely "CALL "

[Robin Vowels]

On Jul 26, 12:03 pm, John Levine <jo...@iecc.com> wrote:
> >> I'm not aware of any ambiguities in PL/I due to the lack of
> >> reserved words. Any amgiguities in C are irrelevant to PL/I.
>
> >If you make some other changes to PL/I, then you can easily
> >get ambiguities. There is, therefor, a tradeoff on not having
> >those features.
>
> Well, sure, but they didn't.  PL/I syntax is unambiguous, even for
> nonsense like this:
>
>     IF THEN = ELSE; THEN IF = THEN; ELSE IF = ELSE;
>
> You can't tokenize it with a naive state machine, but I don't think
> it's any worse than Fortran, which required arbitrary lookahead in a
> statement to tell whether it was an assignment or not.
>
> I gather the motivation was that they expected few programmers to know
> all of PL/I, but rather to program in the Fortran-ish or Cobol-ish
> subsets.  They didn't want keywords for the parts a programmer didn't
> know to bite them.

I'm sure that's the reason. But the practitioners on the
design team undoubtedly baulked at the ramifications of a huge list
of reserved words a la COBOL.

[dpb]

On 7/26/2012 9:23 AM, Robin Vowels wrote:
> On Jul 26, 8:25 am, glen herrmannsfeldt<g...@ugcs.caltech.edu> wrote:
>
>> One feature of many other languages is the ability to call a
>> procedure without a special (not necessarily reserved) keyword
>> (CALL), and not in the context of assignment or other place where
>> an expression is allowed.
>>
>> No reserved words, and convenient (CALL less) procedure calls
>> are both nice features,
>
> I don't see a "CALL Less" procedure call as a "feature".

...

Return value(s) is one feature...

--

[Thomas Koenig]

On 2012-07-25, Richard Maine <nos...@see.signature> wrote:

> reserved words have the problem that whenever you add new ones you
> invalidate previously valid working programs.

From the GCC bugzilla quip file:

Now with 10% more keywords!

[Shmuel Metz]

In <juproi$660$1...@speranza.aioe.org>, on 07/25/2012

at 10:25 PM, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:

>One feature of many other languages is the ability to call a
>procedure without a special (not necessarily reserved) keyword
>(CALL), and not in the context of assignment or other place where
>an expression is allowed.

I'm aware of that; I consider it to be poor language design. OTOH, I
do see a point to languages where every statement has a value, and
would have preferred that PL/I have an Algol-like distintion between =
for assignment and = for comparison.

>No reserved words, and convenient (CALL less) procedure calls are
>both nice features,

I don't see CALL less procedure calls as desirable for procedures that
don't return a value.

[Pete Dashwood]

Richard Maine wrote:
> Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>
>> Robin Vowels wrote:
>
>>> When new keywords are introduced into the language, reserved words
>>> cause some existing programs to fail.
>
>> If you use a proper Editor with Intellisense (Visual Studio/Eclipse
>> are just 2 very good ones...) you will NEVER use a reserved word
>> improperly so that argument carries no weight for me.
>
> That might be so for limitted values of "never". It won't help the
> case where you have existing code and have to deal with a newer
> version of the language that adds new reserved words.

I take your point. Existing code MIGHT contain something which has now
become a reserved word.

But the first time you compile it, it will fail and that should prompt you
to run a Global edit.

>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
consuming.)

>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.)

Agreed.

Now consider it from the point of view of the compiler writer.

If there are NO reserved words how would you implement a language?

[Robert Wessel]

On Mon, 30 Jul 2012 12:14:05 +1200, "Pete Dashwood"
<dash...@removethis.enternet.co.nz> wrote:

>Richard Maine wrote:
>> Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>>
>>> Robin Vowels wrote:
>>
>>>> When new keywords are introduced into the language, reserved words
>>>> cause some existing programs to fail.
>>
>>> If you use a proper Editor with Intellisense (Visual Studio/Eclipse
>>> are just 2 very good ones...) you will NEVER use a reserved word
>>> improperly so that argument carries no weight for me.
>>
>> That might be so for limitted values of "never". It won't help the
>> case where you have existing code and have to deal with a newer
>> version of the language that adds new reserved words.
>
>I take your point. Existing code MIGHT contain something which has now
>become a reserved word.
>
>But the first time you compile it, it will fail and that should prompt you
>to run a Global edit.

I'm not going to comment about how valid the concern actually is, but
the Cobol-85 standard was held up for years over that issue, as
several big participants wanted to avoid new reserved words. The
final (unhappy) compromise was requiring a way to disable reserved
words on a program-by-program basis.

Newer versions of C, for example, have gone out of their way to
minimize the problem by putting most of the new keywords in the
reserved part of the name space (thus we have _Bool and _Complex in
C99), or overload preexisting keywords (*another* new meaning for
"static", new meanings for "auto"). Still some keywords were deemed
important enough to allow into the normal name space ("inline" and
"restrict" were added in C99, although all of the new C11 keywords
have the underscore prefix).

Cobol magnifies the problem with an extremely large list of reserved
words, including many you might reasonably want to use as a name. And
that list has grown substantially over time. By comparison, other
than the two additions in C99, C has not added any keywords in the
public name space since the original 32 defined in C89.

Trivially, make user defined names and "reserved words" syntactically
distinct. "add #var1 to #var2". (Hideous, but it works).

Or consider old-style Basic where all the "verbs" started at the
beginning of a line, plus all variables were one or two characters
long, the second character always being a digit (so no legal variable
names could be the same string as a keyword). Likewise most
assemblers don't prevent you from using most mnemonics as labels
(since they're syntactically distinct). Or something like Forth where
almost all the words can be redefined.

I'm not sure a language designed to have no reserved words is a good
idea, but it's not a big trick to pull off.

[Richard Maine]

Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:

> Robin,...

The post you were replying to was mine - not Robin's, but that's ok.

> 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.)

Yes, lives are at stake, which is a big driver in the requirements. (How
much the requirements actually help safety is another question, and one
I won't try to argue either way at the moment.)

> Now consider it from the point of view of the compiler writer.
>
> If there are NO reserved words how would you implement a language?

Well, since this thread was originally about Fortran, it would seem a
rather obvious example to cite. Fortran has no reserved words (with
minor quibble about intrinsic type names being reserved as type names,
and even that quibble doesn't apply prior to f90). There are existence
proofs of it being possible to implement of Fortran. I'll not try my
hand at a usenet post explaining the details of how one would do that;
I'll stop with claiming the existence proof.

[Qolin]

"Pete Dashwood" wrote in message news:a7m1ue...@mid.individual.net...

<snip>

> Now consider it from the point of view of the compiler writer.
> If there are NO reserved words how would you implement a language?

...Last I heard, Fortran had no reserved words, and it doesn't seem to
prevent a fair number of implementations.

> "I used to write COBOL...now I can do anything."

"If it can't be done in FORTRAN, do it in assembler. And if it can't be done
in assembler, it isn't worth doing".

Qolin

email to qolin at domain dot com
domain is qomputing

[Kerry Liles]

On 7/30/2012 4:20 PM, Qolin wrote:
>
>
> "Pete Dashwood" wrote in message news:a7m1ue...@mid.individual.net...
>
> <snip>
>
>> Now consider it from the point of view of the compiler writer.
>> If there are NO reserved words how would you implement a language?
>
> ...Last I heard, Fortran had no reserved words, and it doesn't seem to
> prevent a fair number of implementations.
>

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?

[Robert Wessel]

On Mon, 30 Jul 2012 16:32:22 -0400, Kerry Liles
<kerry...@gmail.com> wrote:

>On 7/30/2012 4:20 PM, Qolin wrote:
>>
>>
>> "Pete Dashwood" wrote in message news:a7m1ue...@mid.individual.net...
>>
>> <snip>
>>
>>> Now consider it from the point of view of the compiler writer.
>>> If there are NO reserved words how would you implement a language?
>>
>> ...Last I heard, Fortran had no reserved words, and it doesn't seem to
>> prevent a fair number of implementations.
>>
>
>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?

Well,

DO DO=1,10

would work, anyway.

[Richard Maine]

Kerry Liles <kerry...@gmail.com> wrote:

> On 7/30/2012 4:20 PM, Qolin wrote:
> >
> >
> > "Pete Dashwood" wrote in message news:a7m1ue...@mid.individual.net...
> >
> > <snip>
> >
> >> Now consider it from the point of view of the compiler writer.
> >> If there are NO reserved words how would you implement a language?
> >
> > ...Last I heard, Fortran had no reserved words, and it doesn't seem to
> > prevent a fair number of implementations.
> >
>
> 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?

No, but that's because you have the syntax wrong. And without reserved
words, syntax is *VERY* important. It has not been a long time since I
used Fortran. In fact, I was editor of 2 versions of the standard (f95
and f2003). As such, I participated in making sure that the syntax was
still unambiguous when language features were added.

No, Fortran does not have any reserved words (with the quibble I
mentioned about partially reserving intrinsic type names in some
contexts starting in f90). The language syntax ensures that the result
is unambiguous.

If you get the syntax right, your example is

do do = 1 , 10

or alternatively, using the older statement label style

do 100 do = 1 , 10

And yes, both of those will work. I'm afraid I don't have a Fortran
compiler installed on this laptop, or I'd compile a trivial sample
including those lines for you.

[Qolin]

"Kerry Liles" wrote in message news:jv6r13$9b1$1...@dont-email.me...

> On 7/30/2012 4:20 PM, Qolin wrote:
> >
> >
> > "Pete Dashwood" wrote in message
> > news:a7m1ue...@mid.individual.net...
> >
> > <snip>
> >
> >> Now consider it from the point of view of the compiler writer.
> >> If there are NO reserved words how would you implement a language?
> >
> > ...Last I heard, Fortran had no reserved words, and it doesn't seem to
> > prevent a fair number of implementations.
> >
>
> 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?

...rather depends on how you define "work". and whether the source form is
free or fixed. In addition, use (or not) of IMPLICIT NONE is important.

In fixed source form (yuk) spaces are not significant, so without implicit
none, you could get a variable called "dodo" being assigned a value. Trouble
is, 1TO10 won't be interpeted as a variable name coz it starts with a
numeric, and it isn't a valid constant, nor is it an expression AFAICS. So
in this case, "work" would consist of a compile-time error to that effect.

In free form source spaces are significant, so "DO DO" will cause an error,
as will "1 TO 10".

I agree your Fortran is rusty, "TO" is not valid in a do statement, I expect
you meant

DO DO = 1, 10

which is I think allowed by compilers that allow do-loop variables to be of
type real.

So, strange-but-true, Fortran really does have no reserved works. Google
"Fortran reserved words".

[Phillip Helbig---undress to reply]

In article <jv6r13$9b1$1...@dont-email.me>, Kerry Liles

<kerry...@gmail.com> writes:

> 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?

No, but because it is not a valid statement. It is equivalent to

DODO = 1TO10

(in fixed-form source) but a variable name cannot begin with a number.

[dpb]

On 7/30/2012 3:32 PM, Kerry Liles 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?
>

...

Well, excusing the BASIC-like 'TO' instead of the Fortran ','; it should
in fixed source form.

However, to follow-up for Richard M, I find that the old CVF compiler
sorta' cheats -- it doesn't call 'DO' a "reserved" word, it calls it a
"global symbol" and barfs---

C:\Temp> ty do.for
program do
do do = 1,5
write(*,*) do
end do
end

C:\Temp> df /nofree /nologo do.for
do.for
do.for(2) : Error: This global name is invalid in this context. [DO]
do do = 1,5
-----------^
do.for(2) : Error: An INTEGER or REAL data type is required in this
context. [DO]
do do = 1,5
-----------^
do.for(3) : Error: This global name is invalid in this context. [DO]
write(*,*) do
---------------------^

C:\Temp>

OTOH, the O(pen)W(atcom) F77 compiler is perfectly happy...

C:\Temp> wfl386 -quiet doit.for

C:\Temp> doit
1.0000000
2.0000000
3.0000000
4.0000000
5.0000000

C:\Temp>

Frankly, I'm shocked re: CVF's behavior. How about somebody w/ the
Intel descendant?

--

[glen herrmannsfeldt]

In comp.lang.fortran Kerry Liles <kerry...@gmail.com> wrote:

(snip)

> 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):

dodo=1,10
print *,do
enddo
end

(actually tested with gfortran)

-- glen

[dpb]

On 7/30/2012 5:09 PM, glen herrmannsfeldt wrote:
> In comp.lang.fortran Kerry Liles<kerry...@gmail.com> wrote:

...

>> 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).

...

Except when get to rhs the string '1TO10' isn't a legal variable name
(begins w/ numeral instead of letter) so it'll barf there...

--

[glen herrmannsfeldt]

In comp.lang.fortran dpb <no...@non.net> wrote:

(snip)

> However, to follow-up for Richard M, I find that the old CVF compiler
> sorta' cheats -- it doesn't call 'DO' a "reserved" word, it calls it a
> "global symbol" and barfs---

> C:\Temp> ty do.for
> program do
> do do = 1,5
> write(*,*) do
> end do
> end

You can't use DO for two different uses, (other than as a statement).

As a program name, it is an external symbol. (Don't CALL it, though.)

(Consider SUBROUTINE DO)

> C:\Temp> df /nofree /nologo do.for
> do.for
> do.for(2) : Error: This global name is invalid in this context. [DO]
> do do = 1,5
> -----------^

(Also, note that inside a function, the function name is (normally)
NOT an external symbol name, but a local variable.)

FUNCTION DO(X)
DO DO=1,10
ENDDO
RETURN
END

-- glen

[Dick Hendrickson]

do do = l to l0
should work (in some sense of "work").

You can also do
print print, print
or
write (write) write
but not
read (read) read

It's a flexible language. ;)

Dick Hendrickson

[dpb]

On 7/30/2012 5:33 PM, glen herrmannsfeldt wrote:
> In comp.lang.fortran dpb<no...@non.net> wrote:
>
> (snip)
>
>> However, to follow-up for Richard M, I find that the old CVF compiler
>> sorta' cheats -- it doesn't call 'DO' a "reserved" word, it calls it a
>> "global symbol" and barfs---
>
>> C:\Temp> ty do.for
>> program do

...

>
> You can't use DO for two different uses, (other than as a statement).
>
> As a program name, it is an external symbol. (Don't CALL it, though.)

...

Hmmmm...I'll have to think about that a little more in depth--that's
what CVF was complaining over though, you're correct and I overlooked
the obvious.

(I had to rename the file doit.exe to run the previous though, as the JP
Software 4NT command interpreter has an internal command DO and wouldn't
pass even "DO.EXE" to the OS for execution. I forgot to rename it in
the earlier posting so did have an inconsistency in file names--sorry
about that :) ).

C:\Temp copy doit.for clip:
(result pasted below...)

program doit

do do = 1,5
write(*,*) do
enddo
end

C:\Temp> df /nofree /nologo doit.for
doit.for

C:\Temp> doit
1.000000
2.000000
3.000000
4.000000
5.000000

C:\Temp>

VOILA! expected result.

Interestingly, and the reason for the cogitating above, OW F77 had no
problem w/ a program 'do', a real 'do' loop and the variable 'do' as the
index of the loop. CVF did, as you note, preserve the entry name as a
global symbol--I'm not sure if that's required behavior or not or if
that's a F90+ change since F77.

Here's the OW case again--

C:\Temp\doOW.for => clip:
1 file copied
(result pasted below...)
program do
dodo = 1,5
write(*,*) do
enddo
end

C:\Temp> wfl386 -quiet doOW.for

C:\Temp> doOW

1.0000000
2.0000000
3.0000000
4.0000000
5.0000000

C:\Temp>

No confusion about the program, control and variable all being named
'DO' there (which is what I would expect).

--

[dpb]

On 7/30/2012 6:50 PM, dpb wrote:
...

>> As a program name, it is an external symbol. (Don't CALL it, though.)
> ...
>
> Hmmmm...I'll have to think about that a little more in depth--that's
> what CVF was complaining over though, you're correct and I overlooked
> the obvious.

...

> Interestingly, and the reason for the cogitating above, OW F77 had no

> problem w/ a program 'do', a real 'do' loop and the variable 'do'...

OK, I looked it up--that's an extension to F77; it says a program
identifier/name is also global and cannot be duplicated (18.1.1)

So, CVF is ok (whew! :) )

--

[Pete Dashwood]

Richard Maine wrote:
> Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>
>> Robin,...
>
> The post you were replying to was mine - not Robin's, but that's ok.

No, the post I was replying to was Robin's posted in the Reserved Words
thread of comp.lang.cobol.

There was no discussion of Fortran involved.

I see now the post has been cross posted from the Fortran group, but I
wasn't privy to that.

>
>> 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.)
>
> Yes, lives are at stake, which is a big driver in the requirements.
> (How much the requirements actually help safety is another question,
> and one I won't try to argue either way at the moment.)
>
>> Now consider it from the point of view of the compiler writer.
>>
>> If there are NO reserved words how would you implement a language?
>
> Well, since this thread was originally about Fortran, it would seem a
> rather obvious example to cite. Fortran has no reserved words (with
> minor quibble about intrinsic type names being reserved as type names,
> and even that quibble doesn't apply prior to f90). There are existence
> proofs of it being possible to implement of Fortran. I'll not try my
> hand at a usenet post explaining the details of how one would do that;
> I'll stop with claiming the existence proof.

Fair enough. Thanks for the response; sorry about the thread confusion.

[Phillip Helbig---undress to reply]

In article <jv70mh$m5u$1...@speranza.aioe.org>, glen herrmannsfeldt

<g...@ugcs.caltech.edu> writes:
> There is also that old favorite assignment
>
> DO 1 I=1.10

One can avoid being bitten by the typo "." for "," if one gets into the
habit of writing

DO, I=1,10

instead, since in this case

DO, I=1.10

will cause an error. (Of course, IMPLICIT NONE helps more, but was not
standard in F77, though IMPLICIT LOGICAL etc were and would also help
here.)

Yes, the optional comma after DO in a loop was always standard.

[Kerry Liles]

Thanks. And thanks to all others who pointed out HOW rusty my
recollection of FORTRAN! Point(s) taken.

Kerry

[SkippyPB]

On Tue, 31 Jul 2012 09:59:58 -0400, Kerry Liles

Fortran IV has no reserved words. All words have meaning based on
context. For example, the following is legal, though unwise, in
FORTRAN

IF (IF.EQ.THEN) IF=IF*THEN

where the first use of the word IF refers to the keyword for a
selection control structure, while the other uses refer to a variable
named IF; likewise, THEN is used in the context
of a variable in this statement.

Regards,
--

////
(o o)
-oOO--(_)--OOo-

"I plead contemporary insanity."
-- Unknown
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

[glen herrmannsfeldt]

In comp.lang.fortran SkippyPB <swie...@nospam.neo.rr.com> wrote:

(snip, someone wrote)

>>Thanks. And thanks to all others who pointed out HOW rusty my
>>recollection of FORTRAN! Point(s) taken.

> Fortran IV has no reserved words. All words have meaning based on
> context. For example, the following is legal, though unwise, in
> FORTRAN

> IF (IF.EQ.THEN) IF=IF*THEN

Most of the fun cases involve FORMAT or DO.

1 FORMAT(I2)

could be the left side of an assignment, but needs more.

2 FORMAT(I2,6H)=X(I2,I2)

since 6H isn't a legal variable name or constant,
it isn't an assignment.

-- glen

[robert....@oracle.com]

On Monday, July 30, 2012 4:02:56 PM UTC-7, Dick Hendrickson wrote:

> You can also do
>
> print print, print
>
> or
>
> write (write) write
>
> but not
>
> read (read) read

The statement

READ READ.READ.READ READ

is standard conforming. Used in a program

CHARACTER*80 FUNCTION FORMAT(X, Y)
INTENT(IN) X, Y
FORMAT = '(F20.15)'
END

PROGRAM MAIN
INTERFACE OPERATOR(.READ.)
CHARACTER*80 FUNCTION FORMAT(X, Y)
INTENT(IN) X, Y
END FUNCTION
END INTERFACE
READ READ.READ.READ READ
END

Bob Corbett

[Ian Harvey]

Very good - that made me laugh. I think you are missing a comma after
the fourth READ though.

> END
>
> Bob Corbett

With the pointer-is-a-variable thing (if that hasn't been killed?), you
could add a unary overload of READ and maybe get...

READ READ.READ.READ,.READ.READ

[robert....@oracle.com]

You are correct, a comma is required.

Bob Corbett

[robert....@oracle.com]

On Tuesday, July 31, 2012 4:03:29 PM UTC-7, Ian Harvey wrote:
>

> With the pointer-is-a-variable thing (if that hasn't been killed?), you
>
> could add a unary overload of READ and maybe get...
>
>
> READ READ.READ.READ,.READ.READ

Expressions that are references to functions that return data pointers
are still allowed as variables. However, an interpretation passed at
the meeting level at the last meeting prohibits an input list from
starting with an operator.

People did argue for not allowing operator expressions as variables,
but the changes required to remove the feature were larger than some
members of the committee wanted.

Bob Corbett

[glen herrmannsfeldt]

robert....@oracle.com wrote:
(snip)

> The statement

> READ READ.READ.READ READ

I thought it needed a comma, and gfortran seems to agree:

READ READ.READ.READ,READ

and in fixed form:

READREAD.READ.READ,READ

> is standard conforming. Used in a program

> CHARACTER*80 FUNCTION FORMAT(X, Y)
> INTENT(IN) X, Y
> FORMAT = '(F20.15)'
> END

> PROGRAM MAIN
> INTERFACE OPERATOR(.READ.)
> CHARACTER*80 FUNCTION FORMAT(X, Y)
> INTENT(IN) X, Y
> END FUNCTION
> END INTERFACE
> READ READ.READ.READ READ
> END

Pretty neat!

-- glen

[Terence]

Yes, no problems is this form:-

program do
integer do
do 100 do = 1,10
write(*,*) do
100 continue
end

[James Van Buskirk]

<robert....@oracle.com> wrote in message
news:121bb88b-699a-4841...@googlegroups.com...

> CHARACTER*80 FUNCTION FORMAT(X, Y)
> INTENT(IN) X, Y
> FORMAT = '(F20.15)'
> END

> PROGRAM MAIN
> INTERFACE OPERATOR(.READ.)
> CHARACTER*80 FUNCTION FORMAT(X, Y)
> INTENT(IN) X, Y
> END FUNCTION
> END INTERFACE
> READ READ.READ.READ READ
> END

C:\gfortran\clf\read>type read.f90
module readread
type readreadread
real read
end type readreadread
interface operator(.READ.)
module procedure readreadreadread
module procedure readreadreadreadread
module procedure readreadreadreadreadread
end interface operator(.READ.)
contains
function readreadreadread(x,y)
character(80) readreadreadread
type(readreadread), intent(in) :: x(*), y(*)
readreadreadread = '(F20.0)'
end function readreadreadread
function readreadreadreadread(x)
integer readreadreadreadread
type(readreadread), intent(in) :: x(*)
readreadreadreadread = 0
end function readreadreadreadread
function readreadreadreadreadread(x,y)
integer readreadreadreadreadread
integer, intent(in) :: x
type(readreadread), intent(in) :: y(*)
readreadreadreadreadread = 1
end function readreadreadreadreadread
end module readread

program WRITE
use readread
type(readreadread) read(1)
READ READ.READ.READ,READ(.READ.READ.READ.READ)
print*,READ
end program WRITE

C:\gfortran\clf\read>gfortran read.f90 -oread

C:\gfortran\clf\read>read
123
123.000000

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

[dpb]

Which compiler, specifically???

C:\Temp> df /nofree /nologo doit.for
doit.for
doit.for(2) : Error: Conflicting attributes or multiple declaration of
name. [DO]
integer do
----------------^
doow.for(3) : Error: This global name is invalid in this context. [DO]
do 10 do = 1,5
--------------^
doow.for(3) : Error: An INTEGER or REAL data type is required in this
context. [DO]
do 10 do = 1,5
--------------^
doow.for(4) : Error: This global name is invalid in this context. [DO]
write(*,*) do
---------------------^

C:\Temp> copy doit.for clip:
program do
integer do
do 10 do = 1,5
write(*,*) do
10 continue
end

C:\Temp> df /ver
Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C)

The global reserved name for the program DO trumps the use of DO as a
variable--the use of CONTINUE and label doesn't change anything as
compared to the DO...ENDDO form. This is Standard-conforming.

The only compiler I've tried that accepts the above was the Watcom F77
and that is an extension to Standard as it clearly also states that the
program name is a unique name to the program. Nomenclature in the
Standard changed somewhat between F77 and F90+, but the requirement is
the same.

--

[James Van Buskirk]

<robert....@oracle.com> wrote in message
news:c9d55293-1df7-4f1e...@googlegroups.com...

No, just a FORMAT that doesn't require an iolist.

C FILE: R.FOR
MODULE OPS
INTERFACE OPERATOR(.READ.)
MODULE PROCEDURE OP1
END INTERFACE OPERATOR(.READ.)
CONTAINS
FUNCTION OP1(X,Y)
REAL, INTENT(IN) :: X, Y
CHARACTER(*), PARAMETER :: P = '(/)'
CHARACTER(LEN(P)) OP1
OP1 = P
END FUNCTION OP1
END MODULE OPS

PROGRAM PROG
USE OPS

READ READ.READ.READ READ
END PROGRAM PROG

[glen herrmannsfeldt]

James Van Buskirk <not_...@comcast.net> wrote:

(snip)

> No, just a FORMAT that doesn't require an iolist.

In C, formats require an I/O list.
In Fortran, I/O lists require a format (descriptor).
(It should be interesting to have an I/O list and no
list-using descriptors.)

-- glen

[Dick Hendrickson]

On 8/1/12 11:37 AM, glen herrmannsfeldt wrote:
> James Van Buskirk<not_...@comcast.net> wrote:
>
> (snip)
>> No, just a FORMAT that doesn't require an iolist.
>
> In C, formats require an I/O list.

> In Fortran, I/O lists require a format (descriptor).

Well, unformatted I/O doesn't require a FORMAT. That's the syntax
distinction between the two forms ;) .

> (It should be interesting to have an I/O list and no
> list-using descriptors.)

I'm not sure what you mean here, but the standard explicitly requires
that if there is an item to process in the I/O list, there must be a
date-edit-descriptor (I think that's the name). The rule isn't a syntax
rule because it can't be enforced at compile time. It's worded
generally enough to handle things like repeat factors and format
reversion, etc.

Dick Hendrickson
>
> -- glen

[Dick Hendrickson]

Congratulations!

Dick Hendrickson

[robert....@oracle.com]

On Wednesday, August 1, 2012 7:47:20 AM UTC-7, James Van Buskirk wrote:
> <robert....@oracle.com> wrote in message
>
> news:c9d55293-1df7-4f1e...@googlegroups.com...
>
>
>
> > On Tuesday, July 31, 2012 4:03:29 PM UTC-7, Ian Harvey wrote:
>
>
>
> >> Very good - that made me laugh. I think you are missing a comma after
>
> >> the fourth READ though.
>
>
> > You are correct, a comma is required.
>
>
> No, just a FORMAT that doesn't require an iolist.

You are correct that the comma is not
required for fixed source form. However,
the program I meant to write does require
the comma. I did test the code before I
posted it, but because I compiled it as a
fixed source form program, my mistake went
undetected.

I do not understand your comment about a

FORMAT that doesn't require an iolist.

Bob Corbett

[glen herrmannsfeldt]

Dick Hendrickson <dick.hen...@att.net> wrote:

(snip, I wrote)

>> In C, formats require an I/O list.

>> In Fortran, I/O lists require a format (descriptor).

> Well, unformatted I/O doesn't require a FORMAT. That's the syntax
> distinction between the two forms ;) .

Yes, the comment was for formatted output.

As for the previous post, the program would have been just
fine with the old format, even with no list items.

>> (It should be interesting to have an I/O list and no
>> list-using descriptors.)

> I'm not sure what you mean here, but the standard explicitly
> requires that if there is an item to process in the I/O list,
> there must be a date-edit-descriptor (I think that's the name).

write(6,1) 3.0
1 format(1x)
end

> The rule isn't a syntax rule because it can't be enforced at
> compile time. It's worded generally enough to handle things
> like repeat factors and format reversion, etc.

It wouldn't seem so hard to check at compile time, but yes,
it seems that many don't.

-- glen

[James Van Buskirk]

<robert....@oracle.com> wrote in message
news:ef19914c-e1fe-4d8b...@googlegroups.com...

Yeah, you're right. An iolist item can require a corresponding
data edit descriptor but a data edit descriptor doesn't require an
iolist item.

[Dick Hendrickson]

Remember, formats can be expressions constructed at run-time (and, in my
youth, the format was often read in as part of the "header" of the
following data set). Also, it's not obvious how long an I/O list is
(implied dos, zero sized arrays or sections, zero sized character
variables, user defined i/o, ...). Coupled with format reversion that
doesn't necessarily repeat the whole format it isn't possible in the
general case. The Fortran rule is "don't do that." ;)

Dick Hendrickson

[glen herrmannsfeldt]

Dick Hendrickson <dick.hen...@att.net> wrote:

(snip, I wrote)

>> write(6,1) 3.0
>> 1 format(1x)
>> end

>>> The rule isn't a syntax rule because it can't be enforced at
>>> compile time. It's worded generally enough to handle things
>>> like repeat factors and format reversion, etc.

>> It wouldn't seem so hard to check at compile time, but yes,
>> it seems that many don't.

> Remember, formats can be expressions constructed at run-time (and, in my
> youth, the format was often read in as part of the "header" of the
> following data set).

Yes, in that case there can't be a compile time check.
Not even for syntax errors.

In the case of the FORMAT statement, one expects, though probably
can't count on, a compile-time syntax check. (The compiler might
just stuff the whole thing into a string constant.)

In the case of string constant formats:

write(*,'(1x)') 3.0

one could consider it a run-time format that happens to be constant,
but I believe many compilers do check for syntax errors at compile time.

In C, where formats are always either string variables or constants,
compilers are getting better at checking constants at compile time.

> Also, it's not obvious how long an I/O list is
> (implied dos, zero sized arrays or sections, zero sized character
> variables, user defined i/o, ...). Coupled with format reversion that
> doesn't necessarily repeat the whole format it isn't possible in the
> general case. The Fortran rule is "don't do that." ;)

In the case of zero size arrays or implied-DO, yes, the compiler
can't tell. It probably occurs rarely enough that it isn't worth
extra effort to check at complile time, in the cases that can be
detected.

-- glen

[glen herrmannsfeldt]

James Van Buskirk <not_...@comcast.net> wrote:

(snip, someone wrote)

>> I do not understand your comment about a
>> FORMAT that doesn't require an iolist.

> Yeah, you're right. An iolist item can require a corresponding
> data edit descriptor but a data edit descriptor doesn't require an
> iolist item.

Unlike C.

PL/I is similar to Fortran, but with one difference: I/O stops
after the last list item, such that format descriptors that don't
need a list item aren't processed. Not so obvious that one is
better than the other, just different.

-- glen

[Richard Maine]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> Dick Hendrickson <dick.hen...@att.net> wrote:

> > I'm not sure what you mean here, but the standard explicitly
> > requires that if there is an item to process in the I/O list,
> > there must be a date-edit-descriptor (I think that's the name).
>
> write(6,1) 3.0
> 1 format(1x)
> end
>
> > The rule isn't a syntax rule because it can't be enforced at
> > compile time. It's worded generally enough to handle things
> > like repeat factors and format reversion, etc.
>
> It wouldn't seem so hard to check at compile time, but yes,
> it seems that many don't.

Since the format can be a run-time generated string, and the I/O-list
can have zero effective elements because of run-time-dependent
conditions (zero array size, zero implied-do limit), then yes, it is so
hard to check at compile time in general. Sure special cases can be
checked, but that's true of zillions of things that aren't constraints.
The general case cannot be checked at compile time. That's why, as Dick
mentioned, it is not a constraint. Compilers are, of course, free to
check special cases, just like they are free to check for special cases
of many other things that aren't constraints.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[Thomas Koenig]

Of course, there's the classic

DO I = 1.100
PRINT *,I
100 CONTINUE
END

which doesn't do what you expect at first glance.

IMPLICIT NONE

would catch it, and also

IMPLICIT CHARACTER*1 (A-Z)

[Richard Maine]

As would using free source form (in f90 or later).

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[Bill Gunshannon]

In article <k0ji8t$sng$1...@newsreader4.netcologne.de>,

Funny, it would do exactly what I expect. But then, I know Fortran
and therefore know exactly what it is going to do. :-)

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Gordon Sande]

On 2012-08-17 10:07:45 -0300, Richard Maine said:

> Thomas Koenig <tko...@netcologne.de> wrote:
>
>> Of course, there's the classic
>>
>> DO I = 1.100
>> PRINT *,I
>> 100 CONTINUE
>> END
>>
>> which doesn't do what you expect at first glance.

It seems to be missing an ENDDO. Are you sure it compiled without messages?
It however seems close to the classic with

DO 100 I = 1.100
...
100 CONTINUE

[Robin Vowels]

On Aug 17, 5:39 am, Thomas Koenig <tkoe...@netcologne.de> wrote:
> Of course, there's the classic
>
>        DO I = 1.100
>          PRINT *,I
>  100   CONTINUE
>        END
>
> which doesn't do what you expect at first glance.

Only in fixed source form.
It isn't a good idea to write code in fixed source form,
on account of errors that can slip by undiagnosed by the compiler.

The error would be detected in free source form -- with or without
IMPLICIT NONE.

But IMPLICIT NONE is a good idea anyway, for other reasons.

[Dick Hendrickson]

On 9/23/12 9:31 PM, Robin Vowels wrote:
> On Aug 17, 5:39 am, Thomas Koenig<tkoe...@netcologne.de> wrote:
>> Of course, there's the classic
>>
>> DO I = 1.100
>> PRINT *,I
>> 100 CONTINUE
>> END
>>
>> which doesn't do what you expect at first glance.
>
> Only in fixed source form.
> It isn't a good idea to write code in fixed source form,
> on account of errors that can slip by undiagnosed by the compiler.
>
> The error would be detected in free source form -- with or without
> IMPLICIT NONE.

How about
DOI = 1.100

There's no limit to the number of syntax errors people can make.

Dick Hendrickson

[Michel Olagnon]

Dick Hendrickson écrivit :

> On 9/23/12 9:31 PM, Robin Vowels wrote:
>> On Aug 17, 5:39 am, Thomas Koenig<tkoe...@netcologne.de> wrote:
>>> Of course, there's the classic
>>>
>>> DO I = 1.100
>>> PRINT *,I
>>> 100 CONTINUE
>>> END
>>>
>>> which doesn't do what you expect at first glance.
>>
>> Only in fixed source form.
>> It isn't a good idea to write code in fixed source form,
>> on account of errors that can slip by undiagnosed by the compiler.
>>
>> The error would be detected in free source form -- with or without
>> IMPLICIT NONE.
>
> How about
> DOI = 1.100
>
> There's no limit to the number of syntax errors people can make.
>

IF (N .GT. NMAX) THEN K = 1

[Richard Maine]

Michel Olagnon <mola...@ifremer-a-oter.fr> wrote:
>
> IF (N .GT. NMAX) THEN K = 1

I've seen that one in real code that I was helping to debug.

(Irrelevant newsgroups deleted; they didn't even merit a followups-to
header).

[Phillip Helbig---undress to reply]

In article <acd33q...@mid.individual.net>, Michel Olagnon

<mola...@ifremer-a-oter.fr> writes:
> > There's no limit to the number of syntax errors people can make.
>

> IF (N .GT. NMAX) THEN K = 1

Right. Of course, it should probably be

IF (N .GT. NMAX) K = 1

If one also writes DCL (VMS "shell" language), this is dangerous since
there the two forms are

IF expression THEN
statement(s)
ELSE
statement(s)
ENDIF

and

IF expression THEN statement

(Note: no parenthesis required around expression and no ELSEIF.)

[dpb]

On 9/25/2012 2:09 AM, Richard Maine wrote:
> Michel Olagnon<mola...@ifremer-a-oter.fr> wrote:
>>
>> IF (N .GT. NMAX) THEN K = 1
>
> I've seen that one in real code that I was helping to debug.

...

That's the one (or very similar) that Terrance demonstrated not long ago
that the old DOS MS compiler actually used an internal token keyword for
'THEN' to complain over it, isn't it?

--

[Richard Maine]

dpb <no...@non.net> wrote:

> On 9/25/2012 2:09 AM, Richard Maine wrote:
> > Michel Olagnon<mola...@ifremer-a-oter.fr> wrote:
> >>
> >> IF (N .GT. NMAX) THEN K = 1
> >
> > I've seen that one in real code that I was helping to debug.
>

> That's the one (or very similar) that Terrance demonstrated not long ago
> that the old DOS MS compiler actually used an internal token keyword for
> 'THEN' to complain over it, isn't it?

Yep. Or something like that. This was definitely the example (modulo
irrelevant details); I know that because I posted it. I forget the exact
problem with the compiler, but mostly just recall that neither the
compiler nor (at least at first) Terence recognized that it was valid
fixed-source-form code.

That's the compiler that he claims to be bug-free. Not that plenty of
other "features" haven't been observed in it, but they don't count as
bugs. :-)

[Dick Hendrickson]

On 9/25/12 2:09 AM, Richard Maine wrote:
> Michel Olagnon<mola...@ifremer-a-oter.fr> wrote:
>>
>> IF (N .GT. NMAX) THEN K = 1
>
> I've seen that one in real code that I was helping to debug.
>
> (Irrelevant newsgroups deleted; they didn't even merit a followups-to
> header).
>

Then there's the idiot who put a

SAVEALL

statement in every subroutine.

Dick Hendrickson

[dpb]

On 9/25/2012 10:46 AM, Richard Maine wrote:
...

> That's the compiler that he claims to be bug-free. Not that plenty of
> other "features" haven't been observed in it, but they don't count as
> bugs. :-)

That probably didn't count as a bug in his list, either, iirc his
response... :)

--

[Robin Vowels]

On Sep 25, 7:01 am, Dick Hendrickson <dick.hendrick...@att.net> wrote:
> On 9/23/12 9:31 PM, Robin Vowels wrote:
>
>
>
>
>
>
>
>
>
> > On Aug 17, 5:39 am, Thomas Koenig<tkoe...@netcologne.de>  wrote:
> >> Of course, there's the classic
>
> >>         DO I = 1.100
> >>           PRINT *,I
> >>   100   CONTINUE
> >>         END
>
> >> which doesn't do what you expect at first glance.
>
> > Only in fixed source form.
> > It isn't a good idea to write code in fixed source form,
> > on account of errors that can slip by undiagnosed by the compiler.
>
> > The error would be detected in free source form -- with or without
> > IMPLICIT NONE.
>
> How about
>           DOI = 1.100

That also would be detected as an error in fixed-source form
(assuming that IMPLICIT NONE is on, and that there is no variable
name DOI in a declaration).

> There's no limit to the number of syntax errors people can make.

In fixed source form.

[Robin Vowels]

On Sep 26, 2:28 am, Dick Hendrickson <dick.hendrick...@att.net> wrote:
> On 9/25/12 2:09 AM, Richard Maine wrote:> Michel Olagnon<molag...@ifremer-a-oter.fr>  wrote:

>
> >> IF (N .GT. NMAX) THEN K = 1
>
> > I've seen that one in real code that I was helping to debug.
>

> Then there's the idiot who put a
>
>          SAVEALL
>
> statement in every subroutine.

Again, using free source form would have uncovered that error
(probaby even without help from IMPLICIT NONE).