Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: WHy Fortran SELECT statment has an extra CASE at the top?
228 views
Skip to first unread message
Robin Vowels
Jul 25, 2012, 2:14:14 AM7/25/12
to
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.
> 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
Jul 25, 2012, 6:38:51 AM7/25/12
to
In comp.lang.fortran Robin Vowels <robin....@gmail.com> wrote:
(snip regarding reserved words)
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
(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.
> It's certainly easier to treat language words as reserved words.
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.
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.
have done some strange things to avoid problems with new words.
-- glen
Peter Flass
Jul 25, 2012, 10:27:43 AM7/25/12
to
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
> 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.
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
Jul 25, 2012, 3:42:16 PM7/25/12
to
In comp.lang.fortran Peter Flass <Peter...@yahoo.com> wrote:
(snip, someone wrote)
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
(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
>> 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.
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
Jul 25, 2012, 8:24:13 AM7/25/12
to
In <juoibr$ru1$1...@speranza.aioe.org>, on 07/25/2012
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
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
>Well, also it avoids some ambiguities that otherwise occur.
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
Frank Swarbrick
Jul 25, 2012, 6:11:15 PM7/25/12
to
Can I sidetrack the discussion just a bit? I took it upon myself to start learning PL/I a few months ago. Pretty nice language. Too bad I'll never get to really use it. :-(
Anyway, this question about FORTRAN reminded me of a question I have about the PL/I SELECT statement; err "command". Why is there a requirement that SELECT be terminated with END?
SELECT (something)
WHEN (val1)
CALL x;
WHEN (val2)
DISPLAY ("doing the y");
CALL y;
END;
END;
CALL z;
Since WHEN and OTHERWISE are clauses, not commands, why do we need the final END to 'close out' the SELECT? Why not just this?
SELECT (something);
WHEN (val1)
CALL x;
WHEN (val2) DO;
DISPLAY ("doing the y");
CALL y;
END;
CALL z;
END terminates the DO, not the SELECT.
Note that I intentionally changed the indentation.
I am specifically comparing this to an IF, e.g.:
IF something = val1 THEN
CALL a;
ELSE DO;
DISPLAY ("doing the b")
CALL b;
END;
The END here terminates the DO, not the IF. Notice that the conditional statements (treating DO and END as simply beginning and ending multi-command blocks) are only indented 2 spaces.
Why do I care? It's a small and probably to most of you unimportant thing, but if the IF above had an additional condition, and I wanted to convert it to a SELECT, I would first change it to this:
SELECT (something);
WHEN (val1)
CALL a;
OTHERWISE DO;
DISPLAY ("doing the b");
CALL b;
END;
END;
But having the two DOs at the same indentation level makes it look like they are terminating the same "level", which they are not. So I'm stuck with:
SELECT (something)
WHEN (val1)
CALL a;
OTHERWISE DO;
DISPLAY ("doing the b");
CALL b;
END;
END;
Now my conditional statements are indented 4, even though the logic is effectively the same as the IF above.
With COBOL I can convert:
IF something = val1
CALL a;
ELSE
DISPLAY "doing the b"
CALL b;
END-IF
To
EVALUATE something
WHEN val1
CALL a
WHEN OTHER
DISPLAY "doing the b"
CALL b
END-EVALUATE
There is a difference in that COBOL conditional statements are inherently "blocked", so one needs only terminate the conditional (IF or EVALUATE) itself. But I hope the example kind of shows what I'm looking for.
Just wondering! I don't think anyone's going to change PL/I just to satisfy this one pet peeve of mine!
Frank
Anyway, this question about FORTRAN reminded me of a question I have about the PL/I SELECT statement; err "command". Why is there a requirement that SELECT be terminated with END?
SELECT (something)
WHEN (val1)
CALL x;
WHEN (val2)
DISPLAY ("doing the y");
CALL y;
END;
END;
CALL z;
Since WHEN and OTHERWISE are clauses, not commands, why do we need the final END to 'close out' the SELECT? Why not just this?
SELECT (something);
WHEN (val1)
CALL x;
WHEN (val2) DO;
DISPLAY ("doing the y");
CALL y;
END;
CALL z;
END terminates the DO, not the SELECT.
Note that I intentionally changed the indentation.
I am specifically comparing this to an IF, e.g.:
IF something = val1 THEN
CALL a;
ELSE DO;
DISPLAY ("doing the b")
CALL b;
END;
The END here terminates the DO, not the IF. Notice that the conditional statements (treating DO and END as simply beginning and ending multi-command blocks) are only indented 2 spaces.
Why do I care? It's a small and probably to most of you unimportant thing, but if the IF above had an additional condition, and I wanted to convert it to a SELECT, I would first change it to this:
SELECT (something);
WHEN (val1)
CALL a;
OTHERWISE DO;
DISPLAY ("doing the b");
CALL b;
END;
END;
But having the two DOs at the same indentation level makes it look like they are terminating the same "level", which they are not. So I'm stuck with:
SELECT (something)
WHEN (val1)
CALL a;
OTHERWISE DO;
DISPLAY ("doing the b");
CALL b;
END;
END;
Now my conditional statements are indented 4, even though the logic is effectively the same as the IF above.
With COBOL I can convert:
IF something = val1
CALL a;
ELSE
DISPLAY "doing the b"
CALL b;
END-IF
To
EVALUATE something
WHEN val1
CALL a
WHEN OTHER
DISPLAY "doing the b"
CALL b
END-EVALUATE
There is a difference in that COBOL conditional statements are inherently "blocked", so one needs only terminate the conditional (IF or EVALUATE) itself. But I hope the example kind of shows what I'm looking for.
Just wondering! I don't think anyone's going to change PL/I just to satisfy this one pet peeve of mine!
Frank
glen herrmannsfeldt
Jul 25, 2012, 6:25:22 PM7/25/12
to
In comp.lang.fortran Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
(snip, I wrote)
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
(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
> 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.
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
Peter Flass
Jul 25, 2012, 7:11:13 PM7/25/12
to
On 7/25/2012 6:11 PM, Frank Swarbrick wrote:
> Can I sidetrack the discussion just a bit? I took it upon myself to start learning PL/I a few months ago. Pretty nice language. Too bad I'll never get to really use it. :-(
Welcome to the group. There are several free PL/I compilers available
> Can I sidetrack the discussion just a bit? I took it upon myself to start learning PL/I a few months ago. Pretty nice language. Too bad I'll never get to really use it. :-(
if you want to use it.
>
> Anyway, this question about FORTRAN reminded me of a question I have about the PL/I SELECT statement; err "command". Why is there a requirement that SELECT be terminated with END?
>
> SELECT (something)
> WHEN (val1)
> CALL x;
> WHEN (val2)
> DISPLAY ("doing the y");
> CALL y;
> END;
> END;
> CALL z;
>
> Since WHEN and OTHERWISE are clauses, not commands, why do we need the final END to 'close out' the SELECT? Why not just this?
It took me a reread to see what you were asking, but damfino. SELECT is
> Anyway, this question about FORTRAN reminded me of a question I have about the PL/I SELECT statement; err "command". Why is there a requirement that SELECT be terminated with END?
>
> SELECT (something)
> WHEN (val1)
> CALL x;
> WHEN (val2)
> DISPLAY ("doing the y");
> CALL y;
> END;
> END;
> CALL z;
>
> Since WHEN and OTHERWISE are clauses, not commands, why do we need the final END to 'close out' the SELECT? Why not just this?
a "GROUP", like "DO" and groups are terminated by "END"s. I guess it's
just one of those things.
...
>
> But having the two DOs at the same indentation level makes it look like they are terminating the same "level", which they are not. So I'm stuck with:
> SELECT (something)
> WHEN (val1)
> CALL a;
> OTHERWISE DO;
> DISPLAY ("doing the b");
> CALL b;
> END;
> END;
see the end of the SELECT-group.
--
Pete
Robin Vowels
Jul 25, 2012, 9:32:28 PM7/25/12
to
On Jul 26, 8:11 am, Frank Swarbrick <fswarbr...@gmail.com> wrote:
> Can I sidetrack the discussion just a bit? I took it upon myself to start learning PL/I a few months ago. Pretty nice language. Too bad I'll never get to really use it. :-(
>
> Anyway, this question about FORTRAN reminded me of a question I have about the PL/I SELECT statement; err "command". Why is there a requirement that SELECT be terminated with END?
>
> SELECT (something)
> WHEN (val1)
> CALL x;
> WHEN (val2)
> DISPLAY ("doing the y");
> CALL y;
> END;
> END;
> CALL z;
>
> Since WHEN and OTHERWISE are clauses, not commands, why do we need the final END to 'close out' the SELECT?
We don't. You have a superfluous END; however, the code is not
> Can I sidetrack the discussion just a bit? I took it upon myself to start learning PL/I a few months ago. Pretty nice language. Too bad I'll never get to really use it. :-(
>
> Anyway, this question about FORTRAN reminded me of a question I have about the PL/I SELECT statement; err "command". Why is there a requirement that SELECT be terminated with END?
>
> SELECT (something)
> WHEN (val1)
> CALL x;
> WHEN (val2)
> DISPLAY ("doing the y");
> CALL y;
> END;
> END;
> CALL z;
>
> Since WHEN and OTHERWISE are clauses, not commands, why do we need the final END to 'close out' the SELECT?
correct.
This is how it should look:
SELECT (something);
WHEN (val1)
CALL x;
WHEN (val2)
DO;
DISPLAY ("doing the y");
CALL y;
END;
CALL z;
A SELECT statement requires an END because there is no way to tell
where it ends. The OTHERWISE clause is optional, end even if it
weren't the END makes it absolutely clear to the reader and to the
compiler.
Please ignore my immediately preceding post -- I hit the TAB key
and the incomplete post went off.
Robin Vowels
Jul 25, 2012, 9:23:27 PM7/25/12
to
On Jul 26, 8:11 am, Frank Swarbrick <fswarbr...@gmail.com> wrote:
> Can I sidetrack the discussion just a bit? I took it upon myself to start learning PL/I a few months ago. Pretty nice language. Too bad I'll never get to really use it. :-(
>
> Anyway, this question about FORTRAN reminded me of a question I have about the PL/I SELECT statement; err "command". Why is there a requirement that SELECT be terminated with END?
>
> SELECT (something)
> WHEN (val1)
> CALL x;
> WHEN (val2)
> DISPLAY ("doing the y");
> CALL y;
> END;
> END;
> CALL z;
>
> Since WHEN and OTHERWISE are clauses, not commands, why do we need the final END to 'close out' the SELECT? Why not just this?
We don't. For the above code, only one END is required:
>
> Anyway, this question about FORTRAN reminded me of a question I have about the PL/I SELECT statement; err "command". Why is there a requirement that SELECT be terminated with END?
>
> SELECT (something)
> WHEN (val1)
> CALL x;
> WHEN (val2)
> DISPLAY ("doing the y");
> CALL y;
> END;
> END;
> CALL z;
>
> Since WHEN and OTHERWISE are clauses, not commands, why do we need the final END to 'close out' the SELECT? Why not just this?
Robin Vowels
Jul 25, 2012, 9:57:09 PM7/25/12
to
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.
> 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
Jul 25, 2012, 10:03:03 PM7/25/12
to
>> 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
>> 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.
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
Jul 25, 2012, 10:43:42 PM7/25/12
to
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
Jul 26, 2012, 12:16:14 AM7/26/12
to
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
>>> 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.
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.
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.
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.
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
Jul 26, 2012, 1:47:53 AM7/26/12
to
>> 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
>> 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.
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
Jul 26, 2012, 5:53:45 AM7/26/12
to
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.
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.)
--
Richard Maine
email: last name at domain . net
domain: summer-triangle
> 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
> 2 very good ones...) you will NEVER use a reserved word improperly so that
> argument carries no weight for me.
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.)
--
Richard Maine
email: last name at domain . net
domain: summer-triangle
Peter Flass
Jul 26, 2012, 6:08:28 AM7/26/12
to
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
>>> 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
>
"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
Robin Vowels
Jul 26, 2012, 10:23:19 AM7/26/12
to
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".
> 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,
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
Jul 26, 2012, 10:28:16 AM7/26/12
to
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
> >> 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.
design team undoubtedly baulked at the ramifications of a huge list
of reserved words a la COBOL.
Shmuel Metz
Jul 26, 2012, 9:18:27 AM7/26/12
to
In <juproi$660$1...@speranza.aioe.org>, on 07/25/2012
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.
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
>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.
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,
don't return a value.
Frank Swarbrick
Jul 27, 2012, 12:29:20 PM7/27/12
to
On Wednesday, July 25, 2012 7:32:28 PM UTC-6, Robin Vowels wrote:
> On Jul 26, 8:11 am, Frank Swarbrick <fswarbr...@gmail.com> wrote:
> > Can I sidetrack the discussion just a bit? I took it upon myself to start learning PL/I a few months ago. Pretty nice language. Too bad I'll never get to really use it. :-(
> >
> > Anyway, this question about FORTRAN reminded me of a question I have about the PL/I SELECT statement; err "command". Why is there a requirement that SELECT be terminated with END?
> >
> > SELECT (something)
> > WHEN (val1)
> > CALL x;
> > WHEN (val2)
> > DISPLAY ("doing the y");
> > CALL y;
> > END;
> > END;
> > CALL z;
> >
> > Since WHEN and OTHERWISE are clauses, not commands, why do we need the final END to 'close out' the SELECT?
>
> We don't. You have a superfluous END; however, the code is not
SELECT (something);
WHEN (val1)
CALL x;
WHEN (val2) DO;
DISPLAY ("doing the y");
CALL y;
END;
END;
CALL z;
But do you find the following (invalid PL/I) to be ambiguous?
SELECT (something);
WHEN (val1)
CALL x;
WHEN (val2) DO;
DISPLAY ("doing the y");
CALL y;
END;
CALL z;
The SELECT has ended because CALL is not a valid clause of SELECT; therefore SELECT is implicitly (in my opinion) terminated.
> On Jul 26, 8:11 am, Frank Swarbrick <fswarbr...@gmail.com> wrote:
> > Can I sidetrack the discussion just a bit? I took it upon myself to start learning PL/I a few months ago. Pretty nice language. Too bad I'll never get to really use it. :-(
> >
> > Anyway, this question about FORTRAN reminded me of a question I have about the PL/I SELECT statement; err "command". Why is there a requirement that SELECT be terminated with END?
> >
> > SELECT (something)
> > WHEN (val1)
> > CALL x;
> > WHEN (val2)
> > DISPLAY ("doing the y");
> > CALL y;
> > END;
> > END;
> > CALL z;
> >
> > Since WHEN and OTHERWISE are clauses, not commands, why do we need the final END to 'close out' the SELECT?
>
> We don't. You have a superfluous END; however, the code is not
> correct.
> This is how it should look:
>
> SELECT (something);
> WHEN (val1)
> CALL x;
> WHEN (val2)
> DO;
> DISPLAY ("doing the y");
> This is how it should look:
>
> SELECT (something);
> WHEN (val1)
> CALL x;
> WHEN (val2)
> DO;
> CALL y;
> END;
> END;
> CALL z;
>
> A SELECT statement requires an END because there is no way to tell
> where it ends. The OTHERWISE clause is optional, end even if it
> weren't the END makes it absolutely clear to the reader and to the
> END;
> END;
> CALL z;
>
> A SELECT statement requires an END because there is no way to tell
> where it ends. The OTHERWISE clause is optional, end even if it
> compiler.
>
> Please ignore my immediately preceding post -- I hit the TAB key
> and the incomplete post went off.
Yeah, I missed the opening DO for the WHEN (val2). I meant to type this:
>
> Please ignore my immediately preceding post -- I hit the TAB key
> and the incomplete post went off.
SELECT (something);
WHEN (val1)
CALL x;
WHEN (val2) DO;
DISPLAY ("doing the y");
CALL y;
END;
END;
CALL z;
SELECT (something);
WHEN (val1)
CALL x;
WHEN (val2) DO;
DISPLAY ("doing the y");
CALL y;
END;
The SELECT has ended because CALL is not a valid clause of SELECT; therefore SELECT is implicitly (in my opinion) terminated.
Frank Swarbrick
Jul 27, 2012, 12:22:12 PM7/27/12
to
On Wednesday, July 25, 2012 11:47:53 PM UTC-6, 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.
One advantage to COBOL having keywords is that there is no need for statement terminators. A new statement keyword always starts a new statement; so there is no need to explicitly indicate when the previous statement has ended. I know of no other language that works this way; it's interesting.
Frank
> >> 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.
Really? I've been a COBOL programmer for 16 years and, while it occasionally bites me, I rarely have an issue with trying to name a variable after a keyword.
> 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.
One advantage to COBOL having keywords is that there is no need for statement terminators. A new statement keyword always starts a new statement; so there is no need to explicitly indicate when the previous statement has ended. I know of no other language that works this way; it's interesting.
Frank
glen herrmannsfeldt
Jul 27, 2012, 2:47:14 PM7/27/12
to
Frank Swarbrick <fswar...@gmail.com> wrote:
(snip, someone wrote)
>>> Anyway, this question about FORTRAN reminded me of a question
>>> I have about the PL/I SELECT statement; Why is there
> But do you find the following (invalid PL/I) to be ambiguous?
> SELECT (something);
> WHEN (val1)
> CALL x;
> WHEN (val2) DO;
> DISPLAY ("doing the y");
> CALL y;
> END;
> CALL z;
> The SELECT has ended because CALL is not a valid clause of
> SELECT; therefore SELECT is implicitly (in my opinion) terminated.
Works until you try to nest them.
SELECT (something);
WHEN(one)
SELECT (something_else);
CALL z;
Now, how does it know the WHEN(two) belongs to the outer SELECT?
-- glen
(snip, someone wrote)
>>> Anyway, this question about FORTRAN reminded me of a question
>>> a requirement that SELECT be terminated with END?
(snip)
> But do you find the following (invalid PL/I) to be ambiguous?
> SELECT (something);
> WHEN (val1)
> CALL x;
> WHEN (val2) DO;
> DISPLAY ("doing the y");
> CALL y;
> END;
> CALL z;
> The SELECT has ended because CALL is not a valid clause of
> SELECT; therefore SELECT is implicitly (in my opinion) terminated.
SELECT (something);
WHEN(one)
SELECT (something_else);
WHEN (val1)
CALL x;
WHEN (val2) DO;
DISPLAY ("doing the y");
CALL y;
END;
WHEN(two)
CALL x;
WHEN (val2) DO;
DISPLAY ("doing the y");
CALL y;
END;
CALL z;
Now, how does it know the WHEN(two) belongs to the outer SELECT?
-- glen
glen herrmannsfeldt
Jul 27, 2012, 3:20:09 PM7/27/12
to
>> 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.
> Really? I've been a COBOL programmer for 16 years and,
> while it occasionally bites me, I rarely have an issue with
> trying to name a variable after a keyword.
Having still never written any COBOL, I suspect that after
>> 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.
> Really? I've been a COBOL programmer for 16 years and,
> while it occasionally bites me, I rarely have an issue with
> trying to name a variable after a keyword.
a while you stop thinking of single English words for variables.
Maybe only long, multiple word, names, or non-words.
> One advantage to COBOL having keywords is that there is no
> need for statement terminators. A new statement keyword
> always starts a new statement; so there is no need to
> explicitly indicate when the previous statement has ended.
without any continuation indicator, or put multiple statements
on one line?
> I know of no other language that works this way; it's interesting.
consider UTF-8 ( http://en.wikipedia.org/wiki/UTF-8 ).
The code points are arranged such that the first byte can't
be confused with later bytes. In case of an error, you won't
go "out of synch" past the start of the next character.
-- glen
Peter Flass
Jul 27, 2012, 6:46:30 PM7/27/12
to
--
Pete
Pete Dashwood
Jul 29, 2012, 8:14:05 PM7/29/12
to
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
> 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.
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).
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.
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?
Robert Wessel
Jul 30, 2012, 1:37:13 AM7/30/12
to
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
<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.
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.
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
Jul 30, 2012, 4:08:55 PM7/30/12
to
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.
> 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.)
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?
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
Jul 30, 2012, 4:20:38 PM7/30/12
to
"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?
prevent a fair number of implementations.
> "I used to write COBOL...now I can do anything."
in assembler, it isn't worth doing".
Qolin
email to qolin at domain dot com
domain is qomputing
Kerry Liles
Jul 30, 2012, 4:32:22 PM7/30/12
to
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
>
>
> "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.
>
rather doubt:
DO DO=1 TO 10
would work would it?
Robert Wessel
Jul 30, 2012, 4:50:08 PM7/30/12
to
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,
<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?
DO DO=1,10
would work, anyway.
Richard Maine
Jul 30, 2012, 4:52:08 PM7/30/12
to
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
> 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?
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.
Frank Swarbrick
Jul 30, 2012, 4:57:04 PM7/30/12
to
On Friday, July 27, 2012 1:20:09 PM UTC-6, glen herrmannsfeldt wrote:
O1122 SECTION. IF O3235 = "DEBUG ON " SET O4459 TO TRUE END-IF IF
O3235 = "DEBUG OFF" SET O3046 TO TRUE END-IF MOVE ZERO TO O33
- 79 MOVE SPACE TO O3235 ADD 1 TO O2639 EVALUATE O3592 WHEN LOW
- -VALUES MOVE "O" TO O4916 MOVE "O" TO O5121 MOVE O6752 TO O02
- 39 PERFORM O3561 MOVE "C" TO O4916 WHEN "DTD" IF O1107 (30:1)
= "C" MOVE O6752 TO O5045 END-IF PERFORM O2939 PERFORM O2721
WHEN HIGH-VALUES IF O2245 = ZERO PERFORM O3301 PERFORM O2939
ELSE INITIALIZE O3962 O1491 O0592 ADD 1 TO O2639 MOVE "CCCBNN
- "NE N" TO O3737 SUBTRACT 56 FROM O4072 MOVE "O" TO O491
- 6 MOVE "O" TO O5121 MOVE O6752 TO O0239 PERFORM O3561 MOVE "C
- "" TO O4916 END-IF WHEN OTHER IF O1107 (30:1) = "C" MOVE O675
- 2 TO O5045 END-IF PERFORM O2939 PERFORM O0617 END-EVALUATE IF
O2544 (1:O4706) = HIGH-VALUES PERFORM O1059 ELSE MOVE O2544 (
- 1:O4706) TO O3592 IF O1107 (30:1) = "C" MOVE O5045 TO O6752 E
- ND-IF END-IF IF O4459 PERFORM O0105 END-IF GOBACK.
The leading 'dash' is required only if a word (keyword, variable name, etc.) or string literal is split between two lines. Otherwise it is not needed (or even allowed).
Frank
> Frank Swarbrick wrote:
>
>
>
> (snip, someone wrote)
>
> >> 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.
>
>
>
> > Really? I've been a COBOL programmer for 16 years and,
>
> > while it occasionally bites me, I rarely have an issue with
>
> > trying to name a variable after a keyword.
>
>
>
> Having still never written any COBOL, I suspect that after
>
> a while you stop thinking of single English words for variables.
>
>
>
> Maybe only long, multiple word, names, or non-words.
>
>
>
> > One advantage to COBOL having keywords is that there is no
>
> > need for statement terminators. A new statement keyword
>
> > always starts a new statement; so there is no need to
>
> > explicitly indicate when the previous statement has ended.
>
>
>
> So, end-of-line isn't significant? You can split statements
>
> without any continuation indicator, or put multiple statements
>
> on one line?
Yes. The following is absolutely valid COBOL. It was run through an "obfuscation process" so that a compiler could read it easily but a human would have a more difficult time:
>
>
>
> (snip, someone wrote)
>
> >> 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.
>
>
>
> > Really? I've been a COBOL programmer for 16 years and,
>
> > while it occasionally bites me, I rarely have an issue with
>
> > trying to name a variable after a keyword.
>
>
>
> Having still never written any COBOL, I suspect that after
>
> a while you stop thinking of single English words for variables.
>
>
>
> Maybe only long, multiple word, names, or non-words.
>
>
>
> > One advantage to COBOL having keywords is that there is no
>
> > need for statement terminators. A new statement keyword
>
> > always starts a new statement; so there is no need to
>
> > explicitly indicate when the previous statement has ended.
>
>
>
> So, end-of-line isn't significant? You can split statements
>
> without any continuation indicator, or put multiple statements
>
> on one line?
O1122 SECTION. IF O3235 = "DEBUG ON " SET O4459 TO TRUE END-IF IF
O3235 = "DEBUG OFF" SET O3046 TO TRUE END-IF MOVE ZERO TO O33
- 79 MOVE SPACE TO O3235 ADD 1 TO O2639 EVALUATE O3592 WHEN LOW
- -VALUES MOVE "O" TO O4916 MOVE "O" TO O5121 MOVE O6752 TO O02
- 39 PERFORM O3561 MOVE "C" TO O4916 WHEN "DTD" IF O1107 (30:1)
= "C" MOVE O6752 TO O5045 END-IF PERFORM O2939 PERFORM O2721
WHEN HIGH-VALUES IF O2245 = ZERO PERFORM O3301 PERFORM O2939
ELSE INITIALIZE O3962 O1491 O0592 ADD 1 TO O2639 MOVE "CCCBNN
- "NE N" TO O3737 SUBTRACT 56 FROM O4072 MOVE "O" TO O491
- 6 MOVE "O" TO O5121 MOVE O6752 TO O0239 PERFORM O3561 MOVE "C
- "" TO O4916 END-IF WHEN OTHER IF O1107 (30:1) = "C" MOVE O675
- 2 TO O5045 END-IF PERFORM O2939 PERFORM O0617 END-EVALUATE IF
O2544 (1:O4706) = HIGH-VALUES PERFORM O1059 ELSE MOVE O2544 (
- 1:O4706) TO O3592 IF O1107 (30:1) = "C" MOVE O5045 TO O6752 E
- ND-IF END-IF IF O4459 PERFORM O0105 END-IF GOBACK.
The leading 'dash' is required only if a word (keyword, variable name, etc.) or string literal is split between two lines. Otherwise it is not needed (or even allowed).
Frank
Qolin
Jul 30, 2012, 5:10:08 PM7/30/12
to
"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?
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
Jul 30, 2012, 5:15:21 PM7/30/12
to
In article <jv6r13$9b1$1...@dont-email.me>, Kerry Liles
DODO = 1TO10
(in fixed-form source) but a variable name cannot begin with a number.
<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
> 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?
DODO = 1TO10
(in fixed-form source) but a variable name cannot begin with a number.
dpb
Jul 30, 2012, 5:55:08 PM7/30/12
to
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?
--
...
> 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
Jul 30, 2012, 6:09:21 PM7/30/12
to
In comp.lang.fortran Kerry Liles <kerry...@gmail.com> wrote:
(snip)
(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
(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).
> rather doubt:
> DO DO=1 TO 10
> would work would it?
(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
Jul 30, 2012, 6:31:58 PM7/30/12
to
On 7/30/2012 5:09 PM, glen herrmannsfeldt wrote:
> In comp.lang.fortran Kerry Liles<kerry...@gmail.com> 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
Jul 30, 2012, 6:33:00 PM7/30/12
to
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
(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
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
> -----------^
NOT an external symbol name, but a local variable.)
FUNCTION DO(X)
DO DO=1,10
ENDDO
RETURN
END
-- glen
Dick Hendrickson
Jul 30, 2012, 7:02:56 PM7/30/12
to
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
Jul 30, 2012, 7:50:31 PM7/30/12
to
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
...
> 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
write(*,*) do
enddo
end
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
2.0000000
3.0000000
4.0000000
5.0000000
C:\Temp>
'DO' there (which is what I would expect).
--
dpb
Jul 30, 2012, 8:15:26 PM7/30/12
to
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! :) )
--
...
>> 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
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
Jul 30, 2012, 8:24:18 PM7/30/12
to
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
> Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>
>> Robin,...
>
> The post you were replying to was mine - not Robin's, but that's ok.
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.
>> 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.
Phillip Helbig---undress to reply
Jul 31, 2012, 1:10:47 AM7/31/12
to
In article <jv70mh$m5u$1...@speranza.aioe.org>, glen herrmannsfeldt
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.
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
Jul 31, 2012, 9:59:58 AM7/31/12
to
recollection of FORTRAN! Point(s) taken.
Kerry
SkippyPB
Jul 31, 2012, 12:25:41 PM7/31/12
to
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
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
Frank Swarbrick
Jul 31, 2012, 12:44:37 PM7/31/12
to
Thanks!
Frank
glen herrmannsfeldt
Jul 31, 2012, 3:17:45 PM7/31/12
to
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.
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
(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.
> context. For example, the following is legal, though unwise, in
> FORTRAN
> IF (IF.EQ.THEN) IF=IF*THEN
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
Terence
Aug 1, 2012, 12:18:17 AM8/1/12
to
Yes, no problems is this form:-
program do
integer do
do 100 do = 1,10
write(*,*) do
100 continue
end
program do
integer do
do 100 do = 1,10
write(*,*) do
100 continue
end
Thomas Koenig
Aug 16, 2012, 3:39:09 PM8/16/12
to
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)
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
Aug 17, 2012, 9:07:45 AM8/17/12
to
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Bill Gunshannon
Aug 17, 2012, 9:23:22 AM8/17/12
to
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>
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>
Robin Vowels
Sep 23, 2012, 10:31:34 PM9/23/12
to
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.
> 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 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
Sep 24, 2012, 5:01:38 PM9/24/12
to
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
> 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.
DOI = 1.100
There's no limit to the number of syntax errors people can make.
Dick Hendrickson
Michel Olagnon
Sep 25, 2012, 3:00:08 AM9/25/12
to
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
>> 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.
>
Phillip Helbig---undress to reply
Sep 25, 2012, 4:32:44 AM9/25/12
to
In article <acd33q...@mid.individual.net>, Michel Olagnon
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.)
<mola...@ifremer-a-oter.fr> writes:
> > There's no limit to the number of syntax errors people can make.
>
> > 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.)
Robin Vowels
Sep 26, 2012, 10:51:27 AM9/26/12
to
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
> 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
(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.
0 new messages