DO loop names
Prof. Loren Meissner
>
> TEST: DO, TEST = 1, 100, 1
> <insert code here>
> END DO TEST
>
> is not legal.
..
>
> Surely this is an unnecessary restriction.
Somebody might want a procedure named X, with a derived type named X,
and a variable named X. Or even an integer X, and a logical X. Any
sufficiently smart compiler could keep them all apart. But you can't do
it that way. It's a rule. (Fortunately.)
A name can be the same as a keyword, but it cannot be the same as
another name. A construct name is just a name. Essentially, the rule is
that a name must be unique within a scoping unit. (See the beginning of
Sec. 14 in F90 standard; F90 Handbook p. 571; F90 Explained p 93.)
There are a few things that look like exceptions. The components of a
derived type can have names that also appear elsewhere. COMMON block
names. Argument keywords. (The details are all explained in the above
references).
I think this is essentially the definition of scope: a region within
which each name has a fixed binding. SCOPE is a much more complex
subject in F90 than in F77, so a lot more words have to be written to
explain it. There is even an "interpretation" relating to a scope
region that is an interface block.
--Loren Meissner
Phillip Helbig
<insert code here>
END DO TEST
is not legal. With the : after the first test, followed by a DO, and the
TEST in line three following END DO, it seems the compiler could
distinguish between the NAME of the DO loop and the variable.
After learning how nice it is to explicitly declare all variables,
I find myself using DO loop variables like ITEST
TEST: DO, ITEST = 1, 100, 1
<insert code here>
END DO TEST
just to make the name different from the loop.
Surely this is an unnecessary restriction. After all, due to the
wonderful lack of reserved words in FORTRAN, we can write
PROGRAM TEST
REAL :: END, PRINT = 5.0, SQRT(4) = (/1,2,3,4/)
END = PRINT*SQRT(4)
PRINT*, SQRT(4)
PRINT*, END
END
which, however, I wouldn't necessarily recommend. If the compiler
can handle this, surely it could handle the names of DO loops,
especially since the : syntactic sugar helps things out.
Phillip Helbig Tel. .............. +49 40 7252 4110
Hamburger Sternwarte Email .... phe...@hs.uni-hamburg.de
Gojenbergsweg 112 Fax ............... +49 40 7252 4198
D-21029 Hamburg Telex ............... 217884 hamst d
Nigel Arnot
>
>Phillip Helbig <phe...@hs.uni-hamburg.de> wrote:
>>
>> TEST: DO, TEST = 1, 100, 1
>> <insert code here>
>> END DO TEST
>>
>> is not legal.
>>
>> Surely this is an unnecessary restriction.
>
>and a variable named X. Or even an integer X, and a logical X. Any
>sufficiently smart compiler could keep them all apart. But you can't do
>it that way. It's a rule.
fair enough
> (Fortunately.)
>
>A name can be the same as a keyword, but it cannot be the same as
>another name. A construct name is just a name. Essentially, the rule is
>that a name must be unique within a scoping unit. (See the beginning of
>Sec. 14 in F90 standard; F90 Handbook p. 571; F90 Explained p 93.)
>
>There are a few things that look like exceptions.
...
The question in my mind is whether the rule is justified.
If a construct name can never and will never be used in a context
where a variable could also be used, then my feeling is that
you are talking about two different namespaces and it's best
to define them as such.
I'm pretty certain that the namespaces are distinct at present.
So the question is, what future development of F90 could be
blocked by defining construct names as a separate namespace
to other variables, or what added complications it would
cause to compiler writers. If the answer is "none" and "none",
I'd propose that F2000 should allow constructs such as the above.
(Though having said that, I can't see that it's really worth making
a big fuss about)
For the record, C has two namespaces, this code-fragment is OK
(though horrid).
int i=0;
i: i=i+1;
if( i==1) goto i;
Nigel.
Leonard J. Moss
(Nigel Arnot) wrote [concerning the fact that F90 puts variable and
construct names in the same namespace]:
>The question in my mind is whether the rule is justified.
>If a construct name can never and will never be used in a context
>where a variable could also be used, then my feeling is that
>you are talking about two different namespaces and it's best
>to define them as such.
>
>I'm pretty certain that the namespaces are distinct at present.
>So the question is, what future development of F90 could be
>blocked by defining construct names as a separate namespace
>to other variables, or what added complications it would
>cause to compiler writers. If the answer is "none" and "none",
>I'd propose that F2000 should allow constructs such as the above.
>(Though having said that, I can't see that it's really worth making
>a big fuss about)
Consider the following example:
ASSIGN 100 TO TEST
...
GOTO TEST
...
TEST: DO i=1,10
...
ENDDO TEST
...
100 CONTINUE
Construct names look a lot like alphanumeric statement labels (though
they're not really the same thing), and the infamous ASSIGNED GOTO looks a
lot like branches to such labels (if they existed, which they don't).
Though there is absolutely no ambiguity as far as the compiler is
concerned, there might be some mild confusion for human beings (say, for
example, an old FORTRAN IV hand encountering a construct name for the
first time or, conversely, a young Fortran 90 user who's never written a
GOTO of any sort, let alone an ASSIGNED GOTO ;-).
--
Leonard J. Moss <l...@slac.stanford.edu> | My views don't necessarily
Stanford Linear Accelerator Center | reflect those of SLAC,
MS 97; P.O. Box 4349; Stanford, CA 94309 | Stanford or the DOE
Craig Burley
The question in my mind is whether the rule is justified.
If a construct name can never and will never be used in a context
where a variable could also be used, then my feeling is that
you are talking about two different namespaces and it's best
to define them as such.
I'm pretty certain that the namespaces are distinct at present.
No, they are not. They are separable at present, but might not always
be so, and anyway, separability is not the issue.
So the question is, what future development of F90 could be
blocked by defining construct names as a separate namespace
to other variables, or what added complications it would
cause to compiler writers. If the answer is "none" and "none",
I'd propose that F2000 should allow constructs such as the above.
(Though having said that, I can't see that it's really worth making
a big fuss about)
Designing a programming language is not first-and-foremost about
figuring out what compilers can and cannot do easily.
It is first and foremost about figuring out what humans can and
cannot do easily, in terms of concisely, elegantly, and
unambiguously expressing what they mean to say, and sometimes
designing language features so the act of writing code that
meets the requirements of the language tends to stimulate the
programmer's thought in the direction of increased clarity.
When considering a language feature, such as a syntax item, a
semantic interpretation (such as your multiple-namespace idea),
and so on, I find that a good first rule of thumb is to ask
how narrowly you can constrict an average programmer's view of
various examples of the item and still have the programmer
immediately understand what it is doing, without misinterpretation.
The more narrowly you can constrain the view and still have the
interpretation work, that is, the less _context_ a programmer
needs to see to get it right, the "safer" the feature is according
to this first rule of thumb.
So, using an example somebody's already posted, Fortran (a name
denoting all the standards, de facto and otherwise) already allows:
GOTO TEST
Now, in isolation, do average programmers know what this means?
I expect that the answer is "no", because most will think it
means "goto a place in the code that is labeled TEST".
Fortunately, this misfeature is mitigated by the fact that Fortran
does not have alphanumeric labels. So, programmers reading such
code are only at risk of looking fruitlessly for label TEST
(since TEST is an INTEGER variable containing an ASSIGNed label).
However, programmers _writing_ such code and not using popular
safeguards such as IMPLICIT NONE could easily forget to try
defining label TEST and nevertheless think their code compiles
(and maybe even runs) successfully.
Now, add the feature you propose, whereby construct names are
defined with colons, and consider a programmer who sees
GOTO TEST
and then, while perusing the program, sees
TEST: ...
or some such thing.
Even if you limit yourself to the programmers who got the original
"GOTO TEST" question right, that is, programmers who correctly
responded "this is an ASSIGNed GOTO", I believe that you will
find an overly large number of those programmers, upon encountering
the above, might well conclude that "this is a GOTO to the DO loop
labeled TEST" even if they've previously never heard of, or seen,
alphanumeric labels in Fortran. (There aren't any...yet.) I'm
not saying a _majority_ of programmers, but suggesting that
in an environment typical of programmers reading Fortran code,
you'd find that at least 10% misinterpreted the above, which could
result in serious problems (at least some wild-goose chases).
Further, consider what happens in F90 vs. your proposed F2K when
a programmer erroneously writes:
GOTO TEST
...
TEST: DO ...
(This programmer probably thinks, upon seeing some construct names
in other code, that they're really labels. There is, in fact,
little or nothing about Fortran's construct-name facility that
distinguishes it, functionally, from more-general labeling constructs
available in many other popular languages. The fact that Fortran's
construct names are more limited than these general label constructs
does not reveal itself in Fortran code, because syntactically and
semantically, they fit quite well into the mold set by those more-
general constructs. So, unless the code is commented with all the
restrictions on construct names compared to other languages, as
in "TEST: DO ... !TEST is a construct name, you cannot GOTO it",
which is asking a bit much, or all programmers reading the code
are Fortran experts [meaning they're probably not experts in other
languages, much less the problem domain of the program] or always
cross-checking a Fortran language manual, this will look like a
typical label usage just as one finds in other languages.)
Getting back to the above example, when an unsuspecting programmer
writes "GOTO TEST" and "TEST: ..." in the same program, an F90-class
compiler _will_ diagnose the "GOTO TEST" either because the
first usage of TEST is not consistent with the second or because
it doesn't support assigned GOTO.
However, your proposed Fortran language's compilers would _not_
diagnose the above example unless, for example, it disallowed
assigned GOTO (meaning that your language will encourage failure
among many popular implementations of it to diagnose common errors,
because those popular implementations will default to accepting
old, deprecated/deleted constructs without complaint). It's
likely that with IMPLICIT NONE the error will be caught, but
not necessarily -- just as you think it's "natural" for construct
names to be in a different namespace than other local objects,
so the programmer who thinks TEST is a label name might assume
that label names are in a distinct namespace, and thus might
have actually declared an INTEGER variable named TEST. This
would mean the code would be quietly compiled without warning,
and the "GOTO TEST" go to a random place in the computer's
memory.
As you can probably tell, I don't think it is _your_ proposal that
is entirely to "blame" for the reasons I say it must not be adopted
-- the original introductions of things like assigned GOTO (where,
at least, a syntax should have been adopted that, absent any
context, indicated something magical happening -- an indirection --
such as requiring "GOTO .THROUGH.(TEST)" or some such verbosity),
and one might argue, the F90 introduction of construct names that
_look_ like traditional labels but are not syntactically or
semantically distinct (thus leaving open the secondarily remote
possibility of someone writing "GOTO TEST" and getting no diagnostic
about no such label as "TEST" existing), also are reasons your
feature must not be adopted (because they leave open a primarily
remote possibility of someone writing bad code and not knowing it).
This illustrates a problem I see all the time in language design --
and there's a great quote someone made that sums it up, I'm sure,
but I cannot recall it -- and that is that the designers often
throw in a feature that is rarely needed, very handy when needed,
narrow in its capabilities, and for some reason, designed with a
minimal amount of syntax (usually to reduce "verbosity", as if that
matters in such cases).
As these features accrue, the "space" of useful, expressive syntax is
"coated" with expressions that mean very narrow, specific, and
often unexpected things. It has the same effect on the future of
the language that the buildup of gunk in your car's gasoline supply
line has on the efficient operation of its engine.
I'd say that, since assigned GOTO is slated for deletion, since
it never should have been added in its form anyway (since "GOTO TEST"
obviously means "goto label TEST", regardless of whether labels
are allowed to have letters), your feature would be an unwise one
to add, since it is possible that, 30 years from now, there will
be no Fortran code in contemporary use with assigned GOTO, at which
point (if not earlier), proposals will be made to allow "GOTO TEST"
to mean what it always should have. And at that point, generalized
operations on labels, even if not anointed by the standards, will
be frustrated by your artifical separation of the namespaces --
not so much in the compilers, but for the programmers authoring and
maintaining the code.
I'd also add the observation I have, resulting from over 20 years
in language design little-through-big, that as sexy as multiple
namespaces are, they generally create more problems than they solve.
Most of the problems they solve have to do with integrating
separately authored chunks of code (libraries, applications, systems
support code, and so on), and they are chosen as a solution because
mechanized solutions are considered a bit too difficult to provide
(though they're always possible). But the problems they introduce
cannot be mechanized away, as they involve difficulties programmers
have in reading and writing code, not always being able to tell
(in a narrow context) whether namespace separation from the
"foreground namespace" (e.g. the file's macros, the function's local
variables and the program's external functions, the case in most C
programming) is even an issue, much less _which_ namespaces are
involved.
So, as long as authoring and reading code is generally done in a
2D-text model (that is, programs written as a series of lines, each
having a series of characters), it is highly important, IMO, to
keep namespace creation to a minimum in language design. (When
new models become the norm, they'll probably include nearly
omnipresent indicators of pointers to objects that'll indicate
the "nearness", somewhat like proximity of namespace, of every
reference to an object, but at that point, I'm not sure namespaces,
or even names in the sense presently being discussed, are even needed
except to interface to old-model code.)
--
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu