Re: Reserved Words

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

[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."

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

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

[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

[Terence]

Yes, no problems is this form:-

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

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

[robin....@gmail.com]

On Monday, 30 July 2012 10:14:05 UTC+10, Pete Dashwood wrote:
> Richard Maine wrote:
>

> > Pete Dashwood <da.....@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.

Shouldn't have to do that.
It's a waste of everybody's time.

FORTRAN did not have reserved words (and still does not).
PL/I has no reserved words, and has a larger "vocabulary" than COBOL.

The meaning of a word is determined by context.

[robin....@gmail.com]

On Tuesday, 31 July 2012 08:09:21 UTC+10, glen herrmannsfeldt wrote:

> In comp.lang.fortran Kerry Liles <k......@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

Just because it's legal in fixed source form doesn't mean that
you have to use it.
Fixed source form is prone to letting errors slip though undetected.
Free source form doesn't admit such an error.
Nor would it admit the earlier error (though it would it the DO
statement were written
DO1I = 1.10
in which case IMPLICIT NONE would probably catch it.)
But why use such an obsolete form anyway?
DO I = 1.10
would be detected as an error in free source form.

[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

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

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