will Fortran introduce key word in the future standard?
hes selex
do , enddo , and so on.
to avoid the programs such as:
program test
real :: do
do=2.0
end program test
nm...@cam.ac.uk
Vanishingly unlikely. However, it isn't hard to write a tool to
check for them, and it's exactly the sort of warning option that
a compiler should have.
Regards,
Nick Maclaren.
hes selex
name, so I believe introduction of keywords is a reasonable limitation
and the resulting language is a safer and more reliable one.
m_b_metcalf
It has been a basic principle of all recent standards that they be
essentially backwards compatible with previous ones. It is
inconceivable that this will change. Invalidating old programs merely
for the sake of style is something that no committee would undertake.
Regards,
Mike Metcalf
Richard Maine
Amen. There are other issues as well.
One is the result that every time you subsequently add a new keyword to
the language, you invalidate a new set of programs. Plus the
Another is that it violates the principle that you don't have to know
all the complicated parts of the language in order to use the simple
parts. This would mean that a programmer would have to memorize the
entire list of language keywords, even for features of the language that
he didn't do. I've seen that in other languages; no thanks.
Also, you are simply wrong that "very few" programs use Fortran keywords
as variable names. I don't know where you get the data to support that
claim. I get data to refute it from having personally seen many such
programs.
Some people might have a policy of religiously avoiding such situations,
and probably most people have a policy of avoiding confusing use. But
there are some keyword names that are reasonably common as variables.
One example is "if". If you think if that as the English word or Fortran
keyword, you might wonder why it would be so common. But think of it
instead as an abreviation for something like "index of f". I have seen
that one a lot, and even used it on occasion myself. Sure, if you get
"cute" with it, you can write confusing code. But it can also be used in
ways that are perfectly clear.
The list of programs that use special Fortran names as variables becomes
quite a bit larger if you also include intrinsic procedure names; it
isn't clear whether that is the intent or not, but it is certainly
related in that those are names that get special treatment in the
standard and can cause problems if you acidentally use them. In some
ways, those are worse in that accidentally using an intrinsic name for
one of your own procedures can cause the code to work incorrectly
instead of just look confusing; there are ways to avoid that problem,
but it does happen on occasion. The name "index" is one I used to use a
*LOT* before there was an intrinsic of that name. I even recall that
once causing a minor problem (easily fixed, but I had to fix it) when I
wanted to add a reference to the intrinsic in some older code that used
that variable name.
As Nick said, either pursue a separate checking tool or pursue compiler
warning options. I suppose it is at least concievable that one might get
the standard to require such a warning option; I'd say that the odds
were poor if only because it would likely be too low on priority lists,
but it is at least concievable. Making this a prohibition in the
standard just isn't going to happen.
But the cost/benefit just is not there for making the standard prohibit
using leywords as variable names. The costs are large in that, contrary
to the OP's assertion, there is a large number of programs that would be
invalidated. The benefits of putting such a prohibition in the standard,
as opposed to having a compiler warning option, seem marginal.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
dpb
...
> ... This would mean that a programmer would have to memorize the
> entire list of language keywords, even for features of the language that
> he didn't do. I've seen that in other languages; no thanks.
Yeah, Matlab is a prime example of namespace pollution with the zillions
of supplied functions. Not quite the same thing as the keywords, but
certainly related and an example of how "simplicity breeds complexity".
...
> As Nick said, either pursue a separate checking tool or pursue compiler
> warning options. I suppose it is at least concievable that one might get
> the standard to require such a warning option; ...
Until I saw Nick's suggestion I'd never even thought of such an option
as a compiler warning--are there any compilers that implement such? I
don't think I ever ran across one (or least didn't realize it had the
capability if any did)...
--
Richard Maine
> Richard Maine wrote:
[about using language keywords as variable names]
> > As Nick said, either pursue a separate checking tool or pursue compiler
> > warning options. I suppose it is at least concievable that one might get
> > the standard to require such a warning option; ...
>
> Until I saw Nick's suggestion I'd never even thought of such an option
> as a compiler warning--are there any compilers that implement such? I
> don't think I ever ran across one (or least didn't realize it had the
> capability if any did)...
I don't know of any, but it seems like it ought to be easy to do and not
unreasonable to ask for.
dpb
> dpb <no...@non.net> wrote:
>
>> Richard Maine wrote:
> [about using language keywords as variable names]
>>> As Nick said, either pursue a separate checking tool or pursue compiler
>>> warning options. I suppose it is at least concievable that one might get
>>> the standard to require such a warning option; ...
>> Until I saw Nick's suggestion I'd never even thought of such an option
>> as a compiler warning--are there any compilers that implement such? I
>> don't think I ever ran across one (or least didn't realize it had the
>> capability if any did)...
>
> I don't know of any, but it seems like it ought to be easy to do and not
> unreasonable to ask for.
I guess that's at least one data point towards an indication the user
community in general hasn't seen it as a particular problem... :)
--
tho...@antispam.ham
> But
> there are some keyword names that are reasonably common as variables.
> One example is "if".
Actually, that's one I've never used. My most common use of a keyword
name as a variable is probably EXIST. So I wind up with programs that
include EXIST=Exist in an INQUIRE statement. Looks like a tautology.
Myron A. Calhoun
>name, so I believe introduction of keywords is a reasonable limitation
>and the resulting language is a safer and more reliable one.
I'm not sure WHY one would WANT to do the following, but if your
idea prevails, one wouldn't even be ABLE to write such a gem as:
PROGRAM PROGRAM
INTEGER IF, THEN, ELSE, END IF
IF (IF == THEN) THEN
THEN = ELSE
ELSE
ELSE = END IF
END IF
END
which g77 compiles without error.
--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
NRA Life Member & Certified Instructor for Rifle, Pistol, & Home Firearm Safety
Also Certified Instructor for the Kansas Concealed-Carry Handgun (CCH) license
glen herrmannsfeldt
(snip on reserved words)
> Amen. There are other issues as well.
> One is the result that every time you subsequently add a new keyword to
> the language, you invalidate a new set of programs. Plus the
> Another is that it violates the principle that you don't have to know
> all the complicated parts of the language in order to use the simple
> parts. This would mean that a programmer would have to memorize the
> entire list of language keywords, even for features of the language that
> he didn't do. I've seen that in other languages; no thanks.
Having reserved words allows languages like C and Java to do the
equivalent to Fortran subroutine calls without the CALL keyword.
That, in turn, allows many language features to be implemented
as direct library calls. (Leaving out the question of library
routine names being reserved or not.) The base language (not
including the library) can have a fairly small number of keywords,
especially if you reuse them. (static has about three different
meanings in C.) Many C keywords are ambiguous if used for other
than the normal keyword usage.
Though I have never written in COBOL, I have heard that it has
a very large list of reserved words, which one has to keep nearby
to avoid using any of them. Not so convenient.
I vote for not having reserved keywords, and just avoiding
the confusing usage. Having blanks significant in free form Fortran
avoids the old:
DO 1 I=1.2
problem.
> Also, you are simply wrong that "very few" programs use Fortran keywords
> as variable names. I don't know where you get the data to support that
> claim. I get data to refute it from having personally seen many such
> programs.
(snip)
-- glen
glen herrmannsfeldt
In general, keywords of I/O statements are likely to do that.
FILE is a convenient variable name to hold a file name.
Even back to Fortran 66 days, FORMAT was my favorite variable
name to hold a run-time format string.
-- glen
nm...@cam.ac.uk
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>Having reserved words allows languages like C and Java to do the
>equivalent to Fortran subroutine calls without the CALL keyword.
>That, in turn, allows many language features to be implemented
Er, no. Sorry. You don't need reserved words for that. There
are at least three methods that I have seen used. Reserved words
make it easier to work out what on earth someone else's program
is doing, but that is all.
Regards,
Nick Maclaren.
Richard Maine
Yeah. For some reason I personally avoid the name "format". I couldn't
concretely say why I avoid that one when I freely use other simillar
ones. Perhaps it is that some of the worst cases of nearly ambiguous
uses I have seen have involved that name. One I use all the time is
iostat=iostat, which looks simillarly tautological.
tho...@antispam.ham
>> Richard Maine wrote:
>>> But
>>> there are some keyword names that are reasonably common as variables.
>>> One example is "if".
>> Actually, that's one I've never used. My most common use of a keyword
>> name as a variable is probably EXIST. So I wind up with programs that
>> include EXIST=Exist in an INQUIRE statement. Looks like a tautology.
> In general, keywords of I/O statements are likely to do that.
> FILE is a convenient variable name to hold a file name.
Yep, used that one. But it's rare that I'm working with just one file,
so I'm usually using File1, File2, or FileIn, FileOut.
glen herrmannsfeldt
OK, well, if you take the existing C language but change it
to allow keywords as variables you get ambiguities. It would
certainly be possible to avoid them, but you would have to give
up something else.
For C, it isn't only that calls can be made without the CALL
keyword, but that any expressions as allowable as a statement,
and that many statements are of the form keyword followed by
a parenthesized expression.
if(i);
while(j);
are both legal C statements. The problem, then, comes from
using () both for function call arguments and enclosing parts
of statements. Certainly allowing () for grouping in expressions
is useful, so one wouldn't want to remove that.
So, yes, it is the overuse of () that cause ambiguities to
appear in many languages where they otherwise would not occur.
-- glen
Richard Maine
> nm...@cam.ac.uk wrote:
>
> > In article <hd7cjt$1l3$1...@naig.caltech.edu>,
> > glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> >>Having reserved words allows languages like C and Java to do the
> >>equivalent to Fortran subroutine calls without the CALL keyword.
> >>That, in turn, allows many language features to be implemented
> >>as direct library calls. ...
>
> > Er, no. Sorry. You don't need reserved words for that. There
> > are at least three methods that I have seen used. Reserved words
> > make it easier to work out what on earth someone else's program
> > is doing, but that is all.
>
> OK, well, if you take the existing C language but change it
> to allow keywords as variables you get ambiguities.
That's C. It doesn't mean that the principle applies in general.
It also doesn't much correlate with "allowing many language features to
be implemented as direct library calls." Requiring the CALL keyword can
be relevant to syntactic disambiguation, but such a syntax matter
certainly isn't a significant factor in whether the underlying
implementation can be done with a library call, with trivial compiler
translation (say on the same order as the translation necessary to turn
Fortran generic intrinsic procedure references into the specific ones).
Gee. If having "CALL" in the syntax were the only difference, the
compiler could just replace the "CALL" and following blank(s) with
"some_system_prefix_that_canot_match_user_names_". Something like the
old Vax convention of using $ in system library procedure names.
nm...@cam.ac.uk
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>>>Having reserved words allows languages like C and Java to do the
>>>equivalent to Fortran subroutine calls without the CALL keyword.
>>>That, in turn, allows many language features to be implemented
>>>as direct library calls. ...
>
>> Er, no. Sorry. You don't need reserved words for that. There
>> are at least three methods that I have seen used. Reserved words
>> make it easier to work out what on earth someone else's program
>> is doing, but that is all.
>
>OK, well, if you take the existing C language but change it
>to allow keywords as variables you get ambiguities. It would
>certainly be possible to avoid them, but you would have to give
>up something else.
Well, yes, indeed - but C has perhaps the least structured syntax
of any common language except Perl.
>So, yes, it is the overuse of () that cause ambiguities to
>appear in many languages where they otherwise would not occur.
Partly. But let's return to Fortran and permit the omission of
the CALL in subroutine calls. What's the problem?
1) We need () following argument-free subroutines to avoid
clashes with EXIT.
2) FORMAT is an problem, but many people have proposed
abolishing that.
That's pretty well it, as far as I recall.
Regards,
Nick Maclaren.
glen herrmannsfeldt
(snip on subroutine calls without CALL)
> Well, yes, indeed - but C has perhaps the least structured syntax
> of any common language except Perl.
>>So, yes, it is the overuse of () that cause ambiguities to
>>appear in many languages where they otherwise would not occur.
> Partly. But let's return to Fortran and permit the omission of
> the CALL in subroutine calls. What's the problem?
> 1) We need () following argument-free subroutines to avoid
> clashes with EXIT.
and any other keyword only statement
> 2) FORMAT is an problem, but many people have proposed
> abolishing that.
> That's pretty well it, as far as I recall.
READ(5,1)
WRITE(5,1)
EQUIVALENCE(I1,I2)
CONTINUE
RETURN
STOP
END
PAUSE
If you allow insignificant blanks and variable names longer
than six characters:
REAL X(5)
INTEGER Y(5)
LOGICAL Z(5)
DIMENSION A(3)
COMMON B(3)
GOTO 25
ENDFILE 3
REWIND 3
BACKSPACE 3
CALL D(3)
ENTRY E(F)
and as you said:
1 FORMAT(I5)
Many years ago, I tried to find the ambiguities in Fortran 66 if
blanks were significant, but end of record boundaries were not.
(You would also lose much in error detection in source coding errors.)
One I remember is READ:
READ(5,1)
READ(5,1)
vs.
READ(5,1) READ(5,1)
-- glen
Myron A. Calhoun
>a very large list of reserved words, which one has to keep nearby
>to avoid using any of them. Not so convenient.
I *HAVE* taught it, and I recall there were 373 reserved words in COBOL-85.
However, it was NOT particularly INconvenient to choose variable names,
since few of the reserved words contained a hyphen, so one could declare
such variables as TIME-OF-DAY with relative impunity.
And if one did happen to chose a user-declared name that conflicted
with a reserved word, the compiler usually caught it.
Incidentally, COBOL is a "neat" language, once one gets past its
verbosity and the fact that practically EVERYTHING is global!
Richard Maine
> I *HAVE* taught it, and I recall there were 373 reserved words in COBOL-85.
> However, it was NOT particularly INconvenient to choose variable names,
> since few of the reserved words contained a hyphen, so one could declare
> such variables as TIME-OF-DAY with relative impunity.
More annoying were some early versions of BASIC, where there were
essentially reserved sequences of characters. I say "sequences of
characters" instead of words because they were reserved even when they
were not separated out by blanks or other delimiters. For example, one
could not have a variable named CAT because that has an "AT" in it. Your
"INconvenient" above reminded me because it probably would have a
simillar problem illustrated by your capitalized "IN". (Probably it is
too long a name anyway; I forget the limits, but one would not have used
names that long).
I think I even recall it being problematic to have variable names ending
in "A" because something like ...BETA THEN... would see the "AT"
reserved word, even though there was a blank in the middle of it.
Fortunately, one didn't tend to write very large programs in the
language. At least I didn't. I suppose that might partly have been
because it was so early in my programming days, but I don't think much
of anyone used the language for anything we would consider even modest
sized today.
hes selex
> Plus the
> Another is that it violates the principle that you don't have to know
> all the complicated parts of the language in order to use the simple
> parts. This would mean that a programmer would have to memorize the
> entire list of language keywords, even for features of the language that
> he didn't do. I've seen that in other languages; no thanks.
I don't think so, If I use a keyword as a viriable name, The compiler
could give me a error message,
I need not learn "the complicated parts of the language" related to
that keyword, instead, I just need give the virable another name.
As to "very few", sorry ,I have no statistics, Maybe I'm wrong, Maybe
somebody use those words.
I said that just because I hadn't seen ever.
dpb
>> Plus the
>> Another is that it violates the principle that you don't have to know
>> all the complicated parts of the language in order to use the simple
>> parts. This would mean that a programmer would have to memorize the
>> entire list of language keywords, even for features of the language that
>> he didn't do. I've seen that in other languages; no thanks.
>
> I don't think so, If I use a keyword as a viriable name, The compiler
> could give me a error message,
> I need not learn "the complicated parts of the language" related to
> that keyword, instead, I just need give the virable another name.
>
Well, it just ain't a gonna' happen other than _perhaps_ the warning
route owing to the backwards compatibility issue.
--
Gordon Sande
The Fortran i/o almost invites the use of its keywords as user identifiers.
File names are often in variables called FILE or NAME. The use of IOSTAT
to record the iostat result has been noted several times.
I have used both MIN and MAX repeated for their obvious purpose when I
did not need the supplied intrinsics. I heavily use a variable LEN to
locally represent the length of a sparse vector. I have lots of long
multiple part variable names as well as many locally used short ones.
I have not used do, call and similar keyword statements as variable names
although I must own up to using some in the past. I have used start and
end until I decided that end was too gamey and changed it for a longer
stop which then had to be changed as it was also gamey and did not really
have the right meaning on context. (The real trouble with end is that
global searchs in a good editor finds both the variable and the statement.)
Rather than being a problem the lack of reserved words and the use of simple
keywords are aids to understandabale programming. After all the purpose of
the program is to communicate with some idiot (typically the programmer
a half hour later!) the intent of the program. It is a bonus that a machine
is capable of following that intent (even when it is flawed and in need of
revision).
The lack of a large supply of simple words is ably illustrated by Knuth's
sentence on sorting in which he uses many (I recall it as 43) meanings of
the word sort in a single (contorted and long) sentence.
William Clodius
Minor terminology correction. Fortran has keywords. What it doesn't have
is reserved keywords, words that can only be used as keywords. FWIW I
consider not having reserved keywords a minor plus.
--
Bill Clodius
los the lost and net the pet to email
robin
| I'd like to see the introduction of key words, such as program, goto,
| do , enddo , and so on.
These are already keywords..
What you mean are reserved words.
| to avoid the programs such as:
|
| program test
| real :: do
| do=2.0
| end program test
As Fortran has a large number of keywords,
having them as reserved words would make Fortran inconvenient to use,
because it is then necessary to know all of the reserved words
in order not to use one accidentally as a variable.
As well as that, whenever new (reserved) keywords are added to
the language, existing programs that already use such a word as a variable
will fail to compile.
robin
| Only a very few programs used these special words as its variables'
| name,
You don't know that.
Furthermore, when extensions are made to the language,
the introduction of more reserved words will make an existing program
fail when that existing program uses one or more of those new keywords.
GaryScott
>
> - Show quoted text -
I often have a variable named "filename", but I have always avoided
naming variables the same as a fortran statement or keyword. Because
of company standards for variable naming convention, my variables
usually have some prefix and/or suffix, usually identifying the data
type. This is common in "professional" coding.
pehache-tolai
1j8uuoy.jmtdjc1ymswe8N%nos...@see.signature
>
> But there are some keyword names that are reasonably
> common as variables. One example is "if". If you think if that as the
> English word or Fortran keyword, you might wonder why it would be so
> common. But think of it instead as an abreviation for something like
> "index of f".
"f" being the frequency, for instance :-)
> I have seen that one a lot, and even used it on
> occasion myself.
Wow, until now I though I was the only one to use "if" as a variable name
:-)
--
pehache
http://pehache.free.fr/public.html
"Les messageries instantan�es c'est extr�mement pratique sur un plan
professionnel" (Cumbalero, MSN-user, dans fcold)