One of the things that has always bothered me about formatted I/O in 
fortran (from f77 to f2003) is that different read statements are 
required for list-directed I/O and I/O with explicit formats.  I use 
codes that read data files that have the formats intersperced with 
the data.  For example:

....
(4i4)
   1   2   3   4
(5i5)
12345 1234  123   12    1
.....

The codes that read these data files do the obvious thing and read 
the format into a character variable, and then use that character 
variable to read the data.

When creating or modifying data files like this manually, it would 
be convenient to be able to specify list directed I/O.  For example,

(*)
12345,1234,123,12,1

Instead of something that requires you to count columns.  This would 
also allow for repeat counts in the data, arbitrary line breaks, and 
so on.  Fortran does not allow list directed I/O in this way.  
Instead, the programs that read this data must do something like

   read(nin,'(a') cfmt
   if ( cfmt .eq. '(*)' ) then
      read(nin,*) data
   else
      read(nin,cfmt) data
   endif

Is there some reason why Fortran I/O is done the way it is in this 
case?  Why was list-directed I/O done in the special-case way that 
it was rather than the (to me) more obvious and general way?  Is 
there any reason why it could not be changed now to include the 
general way?  Is there any chance that this could be submitted to 
the J3 committee and it would be included in some future revision of 
the language?

$.02 -Ron Shepard

On Sat, 15 Oct 2005 09:30:22 -0500, Ron Shepard
<ron-shepard@NOSPAM.comcast.net> wrote:

[snip]
>(4i4)
>   1   2   3   4
>(5i5)
>12345 1234  123   12    1
[snip]
>   read(nin,'(a') cfmt
>   if ( cfmt .eq. '(*)' ) then
>      read(nin,*) data
>   else
>      read(nin,cfmt) data
>   endif

Why not just do

 read(nin,'(a') cfmt
 read(nin,*) data

or even

read(nin,*)
read(nin,*) data

Ken Plotkin

Ken Plotkin <kplotkin@nospam-cox.net> wrote:

> On Sat, 15 Oct 2005 09:30:22 -0500, Ron Shepard
> <ron-shepard@NOSPAM.comcast.net> wrote:
> 
> [snip]
> >(4i4)
> >   1   2   3   4
> >(5i5)
> >12345 1234  123   12    1
> [snip]
> >   read(nin,'(a') cfmt
> >   if ( cfmt .eq. '(*)' ) then
> >      read(nin,*) data
> >   else
> >      read(nin,cfmt) data
> >   endif
> 
> Why not just do
> 
>  read(nin,'(a') cfmt
>  read(nin,*) data
> 
> or even
> 
> read(nin,*)
> read(nin,*) data

Well, yes, it is simple to simplify an IF block if you just throw away
one half of it, but that doesn't work so well if you actually wanted to
use that half. :-)

Handy as * sometimes is, it is not the universal format and doesn't
replace all of explicit formatting. Ron's examples above didn't happen
to show cases that wouldn't work, but plenty exist. Thats' why a whole
chapter of the stanadrd is devoted to formats. A trivial example would
be

  (4i1)
  1234

On Ron's original question, I don't know a good answer. This one hadn't
occured to me before, but I note the similarity to the problem of
needing a separate read statement for unit=*. The unit= case I've
definitely run into; I'm glad that f2003 finally provides a solution
within the standard. I haven't happened to run into the fmt= case
before, but I see your point.

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

On Sat, 15 Oct 2005 10:51:54 -0700, nospam@see.signature (Richard
Maine) wrote:


[snip]
>  (4i1)
>  1234

Hmmm... I didn't think of that.

>On Ron's original question, I don't know a good answer. This one hadn't
>occured to me before, but I note the similarity to the problem of
[snip]

But I'd say that Ron's IF block really took care of it.

How common is this kind of code, and is it really worthwhile having
the compiler handle it?

BTW - everyone at my place is now using F95.  The biggest problem we
have is that there is so much stuff in it, and it has not dawned on
any of the youngsters that they need to take some time to browse
through the manuals.  More features may help the seasoned, but not the
next generation.

Ken Plotkin

In article <0ju2l1hggrl449e2ud6kpietm73b1cgiil@4ax.com>,
 Ken Plotkin <kplotkin@nospam-cox.net> wrote:

> On Sat, 15 Oct 2005 10:51:54 -0700, nospam@see.signature (Richard
> Maine) wrote:
> 
> 
> [snip]
> >  (4i1)
> >  1234
> 
> Hmmm... I didn't think of that.
> 
> >On Ron's original question, I don't know a good answer. This one hadn't
> >occured to me before, but I note the similarity to the problem of
> [snip]
> 
> But I'd say that Ron's IF block really took care of it.
> 
> How common is this kind of code, and is it really worthwhile having
> the compiler handle it?

In general, I don't know how common it is.  That is partly why I 
posted the question in the first place.  I know that I use codes all 
the time that do this, and when I write code that reads those data 
files, I have to write separate read statements to handle the 
list-directed special case.  BTW, I just showed an integer array 
case, there could be mixtures of integers, reals, characters, and 
now with f90+ even user defined data types that you might want to 
read this way.

In this situation, the compiler can already "handle" the I/O part, 
it is just a little inconvenient to get it to do so.  I would like 
for it to be a little more automatic and orthogonal (I think that is 
the right term).

> BTW - everyone at my place is now using F95.  The biggest problem we
> have is that there is so much stuff in it, and it has not dawned on
> any of the youngsters that they need to take some time to browse
> through the manuals.  More features may help the seasoned, but not the
> next generation.

I have noticed the same thing.  I've been using f90 off and on for 
over 10 years now, and I've been writing new f90/f95 code almost 
exclusively for the past 5 years, and I still have to drag out the 
documentation to see how to use some of the newer features.

$.02 -Ron Shepard

Ron Shepard wrote in message ...
>One of the things that has always bothered me about formatted I/O in
>fortran (from f77 to f2003) is that different read statements are
>required for list-directed I/O and I/O with explicit formats.  I use
>codes that read data files that have the formats intersperced with
>the data.  For example:
>
>...
>(4i4)
>   1   2   3   4
>(5i5)
>12345 1234  123   12    1
>....
>
>The codes that read these data files do the obvious thing and read
>the format into a character variable, and then use that character
>variable to read the data.
>
>When creating or modifying data files like this manually, it would
>be convenient to be able to specify list directed I/O.  For example,

As you are creating these data files,
why not use list-directed input for all the data?
Then you only need to write out the number of items to be read :-
5
12345,1234,123,12,1
and you don't have to worry about formats at all.

>(*)
>12345,1234,123,12,1
>
>Instead of something that requires you to count columns.

That has been covered under another heading.

>  This would
>also allow for repeat counts in the data, arbitrary line breaks, and
>so on.  Fortran does not allow list directed I/O in this way.
>Instead, the programs that read this data must do something like
>$.02 -Ron Shepard

Richard Maine wrote:
>
> On Ron's original question, I don't know a good answer. This one
> hadn't occured to me before, but I note the similarity to the
problem
> of needing a separate read statement for unit=*. The unit= case I've
> definitely run into; I'm glad that f2003 finally provides a solution
> within the standard. I haven't happened to run into the fmt= case
> before, but I see your point.

Some compilers allow/allowed an empty format string  i.e. '( )' to be
equivalent to list-directed, and this would work also when supplied as
a character string for a format. Thus this would meet the OP's
requirement.

David Jones

In article <YZM4f.20351$U51.5209@news-server.bigpond.net.au>,
 "robin" <robin_v@bigpond.com> wrote:

> As you are creating these data files,
> why not use list-directed input for all the data?
> Then you only need to write out the number of items to be read :-
> 5
> 12345,1234,123,12,1
> and you don't have to worry about formats at all.

There are some data that are written with 80i1 formats.  These can 
be long vectors, and when the file formats were designed, it was 
considered important to be able to eliminate the commas and spaces 
between the items to conserve on file space.  Also, list-directed 
output is sometimes a hassle to use.  You have no control over the 
output (that's the point of list directed I/O), so you can't control 
how many spaces are between the items, whether commas and spaces are 
placed between items, or when the linebreaks occur.  This particular 
data file is designed to fit in 80-column records, and that is 
impossible to enforce with list-directed output.  There is also that 
funny thing about the first character of each line being a space 
with list-directed output.  In this context, that space would be a 
wasted character.  The file format was designed originally so that 
the different items could be written with either explicit formats, 
or, if a user wanted to manually modify something, he could change 
an item to use list-directed I/O, which allowed him to avoid 
counting columns, he could use repetition counts, and so on.

$.02 -Ron Shepard

Ken Plotkin <kplotkin@nospam-cox.net> wrote:

 [about having code that has to special-case * as a format]

> How common is this kind of code, and is it really worthwhile having
> the compiler handle it?

I'm not sure on the list-directed vs explicit case. As I said earlier, I
haven't run into that particular one before, so I guess my experience
doesn't provide support for it being common (I tried to word that
carefully to say that it might be common, even if not in my experience).
But...

The similar case of having to special-case unit=* is quite common.
Happens all the time to me, and I've seen several other people gripe
about it also. It happens if you have output that sometimes might go to
"standard output", but other times might go to a file. For example, you
want to be able to either see the output on your screen or save it in a
file. That's very common, and no, shell-level redirection doesn't solve
it because shell-level redirection applies to the whole program, while
you might need control at a much finer level than that. And it is a real
PITA to work around because it can involve numerous READ or WRITE
statements all over the place and with complicated I/O lists and other
things. In one of my programs, I'd guess that handling it with IF tests
would add several hundred lines of code spread over a few dozen source
files; plus a convention for it would have to be added to the code's
API.

The unit=* case anyway is solved in f2003 (with a standardized parameter
name giving an appropriate unit number), and it has a nonstandard, but
mostly portable with caveats solution earlier (write to a unit number
and do possibly system-dependent stuff to get that unit number connected
to standard output; just writing to unit 6 often works, but not always).

One problem with handling special-case syntax with IF blocks is that it
can quickly grow out of hand when there are multiple cases. Try to write
general-purpose code that handles 4 such special syntax elements and you
end up with 16 separate blocks. That's one reason, for example, why the
old nonstandard readonly syntax and similar ilk were a pain - you
couldn't handle them with a variable value because it was special
syntax.

Although I don't see the fmt=* case as coming up that often in things
like this, I also wouldn't see it as something very complicated to
address. I haven't thought through the pros and cons of specific
choices, but just choose some alternative such as fmt='*' or perhaps
fmt='(*)' to mean the same thing and you are almost done. (I'd worry
about the choice fmt='()' mentioned elsewhere, because that's already a
valid format with a different meaning; maybe it couldn't conflict, but
I'd worry about it).

-- 
Richard Maine                     | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov            |       -- Mark Twain

Ron Shepard wrote in message ...
>In article <YZM4f.20351$U51.5209@news-server.bigpond.net.au>,
> "robin" <robin_v@bigpond.com> wrote:
>
>> As you are creating these data files,
>> why not use list-directed input for all the data?
>> Then you only need to write out the number of items to be read :-
>> 5
>> 12345,1234,123,12,1
>> and you don't have to worry about formats at all.
>
>There are some data that are written with 80i1 formats.

The only excample you gave was
"(4i4)
"   1   2   3   4

>  These can
>be long vectors, and when the file formats were designed, it was
>considered important to be able to eliminate the commas and spaces
>between the items to conserve on file space.

Not a consideration now.

>  Also, list-directed
>output is sometimes a hassle to use.  You have no control over the
>output (that's the point of list directed I/O), so you can't control
>how many spaces are between the items, whether commas and spaces are
>placed between items, or when the linebreaks occur.  This particular
>data file is designed to fit in 80-column records, and that is
>impossible to enforce with list-directed output.

If that's a concern, it could be written out as 40I2 format.

>  There is also that
>funny thing about the first character of each line being a space
>with list-directed output.  In this context, that space would be a
>wasted character.

With 2Gb of storage, who cares about a space.

>  The file format was designed originally so that
>the different items could be written with either explicit formats,
>or, if a user wanted to manually modify something, he could change
>an item to use list-directed I/O, which allowed him to avoid
>counting columns, he could use repetition counts, and so on.
>
>$.02 -Ron Shepard

> With 2Gb of storage, who cares about a space.

Even with 2GB available, it might matter. But the real argument is that
quite often, storage is still very restricted. A recent real-life case:
I have 128 kB at my disposal to store a list of invalid items. I can use
an ASCII representation for each item (11 bytes each) or a binary represen-
tation - naively, that would be 8 bytes each, but with some domain know-
ledge, I can reduce that to 6 bytes each. The choice of representation is,
in this case, a make-it-or-break-it choice - the approximately ten thousand
entries that would make possible are too few. The second choice (8 vs 6 bytes)
gives some very welcome safety margin.

Oh, you don't do embedded devices? Poor you, you're neglecting the overwhel-
ming part of your market.

Relevant to this group? Yes, I used some Fortran on that project.

	Jan

> One problem with handling special-case syntax with IF blocks is that it
> can quickly grow out of hand when there are multiple cases. 

So the conclusion from this discussion would be a strong suggestion to the
writer of standards to avoid special cases, here special-case syntax, if
at all possible.

You mentioned OPEN et al. options as another case, and we've had formats
and unit numbers as well. What else comes to people's minds in this con-
nection with regard to the current Fortran standards?

	Jan

Jan Vorbr�ggen wrote:
>> One problem with handling special-case syntax with IF blocks is
that
>> it can quickly grow out of hand when there are multiple cases.
>
> So the conclusion from this discussion would be a strong suggestion
> to the writer of standards to avoid special cases, here special-case
> syntax, if at all possible.
>
> You mentioned OPEN et al. options as another case, and we've had
> formats and unit numbers as well. What else comes to people's minds
> in this con- nection with regard to the current Fortran standards?
>

A facility that I would find useful is a combined read-write statement
with an explicit keyword to choose between reading and writing, and
keeping all the other keywords of the exising read and write
statements, together with additional keywords from the OPEN statement
so that a range of possibilities of formatted and unformatted (and
list-directed) i/o can be accomodated. This would make it
substantially easier to have single block of code for reading and
writing a file without have to ensure that separate read and write
statements correspond properly.

The idea would be that all features chosen for the i/o would be
pre-selected by setting variables for the keywords in a single place
and these variables would be used for all OPEN and reading and writing
statements.

David Jones

In article <3rjlllFjbbifU1@individual.net>,
Jan Vorbr�ggen  <jvorbrueggen-not@mediasec.de> wrote:
>> One problem with handling special-case syntax with IF blocks is that it
>> can quickly grow out of hand when there are multiple cases. 
>
>So the conclusion from this discussion would be a strong suggestion to the
>writer of standards to avoid special cases, here special-case syntax, if
>at all possible.
>
>You mentioned OPEN et al. options as another case, and we've had formats
>and unit numbers as well. What else comes to people's minds in this con-
>nection with regard to the current Fortran standards?

Some time ago I mentioned here that if n is an initialization expression
you can declare an array variable
  REAL, DIMENSION(n) :: x
but you can't write a function statement returning an array with
  REAL, DIMENSION(n) FUNCTION f(x)
with or without the :: or the comma. I thought that was a pity. I think 
the only reply at the time came from someone who'd prefer not to put
the type of f in the function statement but instead use an extra line:
  FUNCTION f(x)
  REAL, DIMENSION(n) :: f

John Harper, School of Mathematics, Statistics and Computer Science, 
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

In article <3rjlllFjbbifU1@individual.net>,
Jan Vorbr�ggen  <jvorbrueggen-not@mediasec.de> wrote:
>> One problem with handling special-case syntax with IF blocks is that it
>> can quickly grow out of hand when there are multiple cases. 
>
>So the conclusion from this discussion would be a strong suggestion to the
>writer of standards to avoid special cases, here special-case syntax, if
>at all possible.
>
>You mentioned OPEN et al. options as another case, and we've had formats
>and unit numbers as well. What else comes to people's minds in this con-
>nection with regard to the current Fortran standards?

Three cases where analogous things have different syntax are

(1) Element n of a rank 1 array a is a(n) 
but element n of a character string b is b(n:n)

(2) An implied-do loop with stride 1 needs (... , i=m,n) 
but a FORALL statement with stride 1 needs FORALL(i=m:n) ...

(3) In most declarations :: may appear between type and variable-name, 
and it must in certain circumstances, but :: must not appear between 
FUNCTION and function-name nor between SUBROUTINE and subroutine-name, 
and one must say RESULT(x) not RESULT::x or RESULT x

Am I the only f95 programmer who gets reminded by compilers that I have
used : or :: when I shouldn't have, or failed to use : or :: when I 
should have?

John Harper, School of Mathematics, Statistics and Computer Science, 
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

John Harper <harper@mcs.vuw.ac.nz> wrote:

> Three cases where analogous things have different syntax are
> 
> (1) Element n of a rank 1 array a is a(n) 
> but element n of a character string b is b(n:n)

Well... though I'll admit to also occasionally wishing that character n
of a character string could be accessed as b(n),

1) I think it gives ride to syntactic ambiguity when you add arrays of
strings.

2. I'd argue that it isn't that parallel. It isn't after all, an element
of a character array (that you could use the b(n) notation for). Instead
it is a substring that happens to have length 1. Even though it is of
length 1, it is still a string and has all the properties of a string.
I'd say that in that regard it is similar to the slice a(n:n) of an
array. That slice is of size 1, but still is an array and has all the
properties of an array.

> (2) An implied-do loop with stride 1 needs (... , i=m,n) 
> but a FORALL statement with stride 1 needs FORALL(i=m:n) ...

No comment (other than that I never use FORALL, so I don't much notice
this).
 
> (3) In most declarations :: may appear between type and variable-name,
> and it must in certain circumstances, but :: must not appear between 
> FUNCTION and function-name nor between SUBROUTINE and subroutine-name,
> and one must say RESULT(x) not RESULT::x or RESULT x

Well, I don't get hit by this one either. Style differences, but my
style is to not regard a function statement as a declaration at all. I
put the declaration of the result variable inside the function. I find
that there are all kinds of oddities and inconsistencies that result
from trying to declare the type on the function statement. It has a
bunch of special-case callouts in the syntax already, and that isn't
enough to catch everything. Notably, the function statement is
inherently before everything else in the function, but it gets an
exception to some of the ordering rules (but not to others).

I don't think it has ever occurred to me to say result x or result::x. I
suspect they would end up causing ambiguities, though I didn't sit down
and try to come up with one just now; I do recall that the bind(c) stuff
went through several iterations of accidental ambiguities during drafts.
My personal opinion is that too much stuff is lumped into the function
statement (and to a lesser degree, the subroutine statement).

But I agree that these are mostly differences in personal preference
(except for the cases that there are ambiguities) rather than questions
of better/worse.

In any case, whatever one's style preferences on these matters, I don't
think these fall in the same category as some of the I/O questions that
started this. It isn't as though you are going to want to be able to put
a function or subroutine header into a character variable and then have
the value of that variable determine at run-time whether it is a
function or subroutine.  (Well, ok, there is application for that, but
such things are called interpreters). These are, of course, fine things
to debate - I just think it is a different issue than the original here.
(Ok,  cxall it usenet topic drift - something I'm often enough guilty of
myself).

To me, the message of those things was not to avoid syntax
irregularities. That is, of courtse, a good general principle, but I
don't think that particular principle catches the issue. I think the
issue was one of putting things into compile-time syntax that could
plausibly be run-time varaible values instead. If you make everything a
run-time variable value, then you just defined an interpreter, which has
some good points, but also some definite perfirmance "issues".

But there isn't a realistic performance issue that requires knowing at
compile time that list-directed I/O is used instead of explicit
formatting - or that a file is to be opened only for reading.

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

In article <1129774192.14947@bats.mcs.vuw.ac.nz>,
 harper@mcs.vuw.ac.nz (John Harper) wrote:

> >So the conclusion from this discussion would be a strong suggestion to the
> >writer of standards to avoid special cases, here special-case syntax, if
> >at all possible.
> >
> >You mentioned OPEN et al. options as another case, and we've had formats
> >and unit numbers as well. What else comes to people's minds in this con-
> >nection with regard to the current Fortran standards?

Did someone mention OPEN()?  If so, my newsreader missed the post.

OPEN was standardized in f77, but it was a vendor extension before 
that.  It was not a function or subroutine subprogram, it was a 
statement, and it had a lot of unique syntax (positional and keyword 
arguments, default values, optional arguments, etc.).  Since f90 
however, all of this is now available with standard subprograms, so 
all of the OPEN() statements could, in principle, be changed to 
"CALL OPEN()".  And if they change OPEN, they should also change 
CLOSE() and INQUIRE().  For backward compatibility, compilers would 
have to support both the old statement syntax and also the new 
subroutine syntax.  That might be enough to kill off the idea.

Another idea along these lines is to overlay all of the complex 
arithmetic with an "intrinsic" derived type syntax.  This would 
allow, for example, the real or the imaginary component of a complex 
variable to be accessed directly, something that cannot be done with 
the current complex syntax.

$.02 -Ron Shepard

Richard Maine wrote:
> John Harper <harper@mcs.vuw.ac.nz> wrote:

>>Three cases where analogous things have different syntax are

>>(1) Element n of a rank 1 array a is a(n) 
>>but element n of a character string b is b(n:n)

> Well... though I'll admit to also occasionally wishing that character n
> of a character string could be accessed as b(n),

> 1) I think it gives ride to syntactic ambiguity when you add arrays of
> strings.

> 2. I'd argue that it isn't that parallel. It isn't after all, an element
> of a character array (that you could use the b(n) notation for). Instead
> it is a substring that happens to have length 1. 

Some languages use (start,end) for substrings and some (start,length).
It might be a little more common for the length to be constant, than
for the end to be constant.  It doesn't follow the : notation so well, 
though.

If the position is a more complicated expression

b(int(sqrt(x**2+y**2):int(sqrt(x**2+y**2))))=char(1+ichar(b(int(sqrt(x**2+y**2):int(sqrt(x**2+y**2))))))

compare to C's

b[int(sqrt(x*x+y*y))]++;

It is a little late now, though.

-- glen

Richard Maine wrote:
....
> Well... though I'll admit to also occasionally wishing that character
> n of a character string could be accessed as b(n),
>
> 1) I think it gives ride to syntactic ambiguity when you add arrays of
> strings.

Actually not.  The ambiguity is that string(n) is assumed to
be a function reference while string(n:n) is seen to be a
substring.  Only IMPLICIT NONE would have eliminated
tha ambiguity.  That wasn't there in F77.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

glen herrmannsfeldt wrote:
> If the position is a more complicated expression
>
>
b(int(sqrt(x**2+y**2):int(sqrt(x**2+y**2))))=char(1+ichar(b(int(sqrt(x**2+y*
*2):int(sqrt(x**2+y**2))))))
>
> compare to C's
>
> b[int(sqrt(x*x+y*y))]++;
>
> It is a little late now, though.

Little late for what?  Arithmetic on characters is not particularly
common.  And assignment operators (like ++) are known to be
generally bad for programmer productivity regardless of
any occasional advantage of the usually overly terse uses
of them.  I agree referencing a single character ought not
to require the : (that was a really *big* mistake of the F77
standard).  But, even that's not too awful:

   itemp=int(sqrt(x**2+y**2)
   b(itemp:itemp) = char(1+ichar(b(itemp:itemp)))

That's not so bad.  Especially since, as I say, arithmetic
on characters is very seldom needed or desirable.  To be
sure, it would be better still to do:

   itemp=int(sqrt(x**2+y**2)
   b(itemp) = char(1+ichar(b(itemp)))

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

Ron Shepard <ron-shepard@NOSPAM.comcast.net> wrote:

> Did someone mention OPEN()?  If so, my newsreader missed the post.

Yes. I did, in particular regard to the nonstandard readonly extension
in f77 being specifiabel only by compile-time syntax.

> all of the OPEN() statements could, in principle, be changed to 
> "CALL OPEN()".

Well, possibly for OPEN, but certainly not for, say, READ/WRITE. And I'm
afraid I can't see any significant benefit to changing OPEN to a
subroutine in the standard, even if it worked. That seems like a
spurious change with nowhere near enough benefit to justify the change.
It sure isn't anythng I'd vote for without seeing a *LOT* more
justification.

But I do think that part of the point someone else mentioned was that
you can write your own equivalent of an OPEN subroutine, but it is
painful if the OPEN statement has syntax like the old nonstandard
readonly (and someone mentioned other examples I think) that are
expressed only in syntax and not as variable values.

> Another idea along these lines is to overlay all of the complex 
> arithmetic with an "intrinsic" derived type syntax.  This would 
> allow, for example, the real or the imaginary component of a complex 
> variable to be accessed directly, something that cannot be done with 
> the current complex syntax.

That's proposed and I think will be in the next standard... that is
unless some people get their way in attempts to take a simple idea and
turn it into a rework of the whole type system and a rewrite of half the
standard, in which case the proposal will die.  :-( Ok,I slightly
exagerate, but that's more or less my impression of one paper I've seen.

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

James Giles wrote:
| Richard Maine wrote:
| ...
|| Well... though I'll admit to also occasionally wishing that character
|| n of a character string could be accessed as b(n),
|| 
|| 1) I think it gives ride to syntactic ambiguity when you add arrays of
|| strings.
| 
| Actually not.  The ambiguity is that string(n) is assumed to
| be a function reference while string(n:n) is seen to be a
| substring.  Only IMPLICIT NONE would have eliminated
| tha ambiguity.  That wasn't there in F77.

Well, I don't see it as you state it. One could also argue that 
there's an ambiguity that foo(n) is assumed to be a function 
reference unless foo is declared as an array. However, the
ambiguity is resolvable (even without IMPLICIT NONE) because
compiler assumes that everything not declared as an array
(or character string) is a function reference.

However, I have a hunch that possible ambiguities can arise in
arrays of characters, but I don't see it offhand. Anyone?

-- 
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Jugoslav Dujic wrote:
> James Giles wrote:
>> Richard Maine wrote:
>> ...
>>> Well... though I'll admit to also occasionally wishing that
>>> character n of a character string could be accessed as b(n),
>>>
>>> 1) I think it gives ride to syntactic ambiguity when you add arrays
>>> of strings.
>>
>> Actually not.  The ambiguity is that string(n) is assumed to
>> be a function reference while string(n:n) is seen to be a
>> substring.  Only IMPLICIT NONE would have eliminated
>> tha ambiguity.  That wasn't there in F77.
>
> Well, I don't see it as you state it. One could also argue that
> there's an ambiguity that foo(n) is assumed to be a function
> reference unless foo is declared as an array. However, the
> ambiguity is resolvable (even without IMPLICIT NONE) because
> compiler assumes that everything not declared as an array
> (or character string) is a function reference.

Exactly.  They *could* have made the decision that anything
not declared as an array *or* a string would be assumed to
be a function if it appears sunscripted.  They didn't.  They
decided to consider strings to be scalars and the presence
of any simple subscript was assumed to indicate that it was
a function call.  I think strings should *not* be considered
scalars and that the decision should have been to treat strings
more like variants of arrays (with different compare operations
and assignment rules, but otherwise must the same as rank-one
arrays).

> However, I have a hunch that possible ambiguities can arise in
> arrays of characters, but I don't see it offhand. Anyone?

There aren't any.  We've been through this before (I think
it was right here in the newsgroup).  For an array of characters,
the first (or only) subscript is the array subscript.  The second
subscript (if present) is the substring spec.  There can be no
problem if the colon is omitted in the substring spec if this were
the only issue.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

James Giles wrote:
| Jugoslav Dujic wrote:
|| James Giles wrote:
||| Richard Maine wrote:
||| ...
|||| Well... though I'll admit to also occasionally wishing that
|||| character n of a character string could be accessed as b(n),
|||| 
|||| 1) I think it gives ride to syntactic ambiguity when you add arrays
|||| of strings.
||| 
||| Actually not.  The ambiguity is that string(n) is assumed to
||| be a function reference while string(n:n) is seen to be a
||| substring.  Only IMPLICIT NONE would have eliminated
||| tha ambiguity.  That wasn't there in F77.
|| 
|| Well, I don't see it as you state it. One could also argue that
|| there's an ambiguity that foo(n) is assumed to be a function
|| reference unless foo is declared as an array. However, the
|| ambiguity is resolvable (even without IMPLICIT NONE) because
|| compiler assumes that everything not declared as an array
|| (or character string) is a function reference.
| 
| Exactly.  They *could* have made the decision that anything
| not declared as an array *or* a string would be assumed to
| be a function if it appears sunscripted.  They didn't.  They
| decided to consider strings to be scalars and the presence
| of any simple subscript was assumed to indicate that it was
| a function call.  I think strings should *not* be considered
| scalars and that the decision should have been to treat strings
| more like variants of arrays (with different compare operations
| and assignment rules, but otherwise must the same as rank-one
| arrays).

Ahh, I wasn't aware of that; you mean that:

character(10)    foo
write(*,*) foo(1)

is legal, regarded in isolation (i.e. foo(1) is assumed to be an
external function reference.)

Checking... yep, it's true, no syntax error, just an "unresolved
external". Too bad. Learn something new every day :-).

|| However, I have a hunch that possible ambiguities can arise in
|| arrays of characters, but I don't see it offhand. Anyone?
| 
| There aren't any.  We've been through this before (I think
| it was right here in the newsgroup).  For an array of characters,
| the first (or only) subscript is the array subscript.  The second
| subscript (if present) is the substring spec.  There can be no
| problem if the colon is omitted in the substring spec if this were
| the only issue.

I must confess I don't recall that discussion, and I have been 
following clf actively for about 5 years. It's quite possible, 
of course, that it's just my memory. If you have a reference handy, 
I'd appreciate.

-- 
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

In article <3rp1j1FkiqecU1@individual.net>,
 "Jugoslav Dujic" <jdujic@yahoo.com> wrote:

> James Giles wrote:
> ||| Actually not.  The ambiguity is that string(n) is assumed to
> ||| be a function reference while string(n:n) is seen to be a
> ||| substring.  Only IMPLICIT NONE would have eliminated
> ||| tha ambiguity.  That wasn't there in F77.
[...]
> 
> Ahh, I wasn't aware of that; you mean that:
> 
> character(10)    foo
> write(*,*) foo(1)
> 
> is legal, regarded in isolation (i.e. foo(1) is assumed to be an
> external function reference.)

I think I have followed most of this discussion, but I don't 
understand the above comment about IMPLICIT NONE.  How would 
IMPLICIT NONE (which was not in f77) have helped to eliminate this 
ambiguity?

$.02 -Ron Shepard

Ron Shepard wrote:
> 
> In article <3rp1j1FkiqecU1@individual.net>,
>  "Jugoslav Dujic" <jdujic@yahoo.com> wrote:
> 
> > James Giles wrote:
> > ||| Actually not.  The ambiguity is that string(n) is assumed to
> > ||| be a function reference while string(n:n) is seen to be a
> > ||| substring.  Only IMPLICIT NONE would have eliminated
> > ||| tha ambiguity.  That wasn't there in F77.
> [...]
> >
> > Ahh, I wasn't aware of that; you mean that:
> >
> > character(10)    foo
> > write(*,*) foo(1)
> >
> > is legal, regarded in isolation (i.e. foo(1) is assumed to be an
> > external function reference.)
> 
> I think I have followed most of this discussion, but I don't
> understand the above comment about IMPLICIT NONE.  How would
> IMPLICIT NONE (which was not in f77) have helped to eliminate this
> ambiguity?

I'm guessing it is assumed that the definition of foo as a CHARACTER
variable combined w/ IMPLICIT NONE was assumed by Jugoslav to make the
subsequent reference to foo(1) be recognized as an (improper) substring
refererence rather than a function reference.

Whether this is prescribed behavior I'm not sure...

> I think I have followed most of this discussion, but I don't 
> understand the above comment about IMPLICIT NONE.  How would 
> IMPLICIT NONE (which was not in f77) have helped to eliminate this 
> ambiguity?

Because then the name would need to be declared by the programmer -
no need for the compiler to perform implicit typing and guessing
at what the code is supposed to mean. Well, not guessing of course:
but the rules were written such that only one interpretation was
possible, which couldn't have been done if string(n) referenced a
substring.
	
	Jan

In article <3rpo7hFki0skU1@individual.net>,
 Jan Vorbr�ggen <jvorbrueggen-not@mediasec.de> wrote:

> > I think I have followed most of this discussion, but I don't 
> > understand the above comment about IMPLICIT NONE.  How would 
> > IMPLICIT NONE (which was not in f77) have helped to eliminate this 
> > ambiguity?
> 
> Because then the name would need to be declared by the programmer -
> no need for the compiler to perform implicit typing and guessing
> at what the code is supposed to mean.

The character variable was declared in the example, and assuming 
there was not an IMPLICIT CHARACTER declaration in effect, it must 
be declared anyway.  It just didn't click with me how IMPLICIT NONE 
would have helped anything.

> Well, not guessing of course:
> but the rules were written such that only one interpretation was
> possible, which couldn't have been done if string(n) referenced a
> substring.

Yes, this part I followed, I think.  I was just unclear how IMPLICIT 
NONE changed anything.

If the name were declared in an EXTERNAL statement, then that would 
remove the ambiguity in f77.  That still works in f90, and in f90 
there are other ways (contained functions, module functions) that 
the ambiguity might be removed.

My other comments (about turning OPEN into a subroutine and COMPLEX 
into a derived type) were really a comment about how the order that 
features were added to the language, and the need for backward 
compatibility, come into play.  *IF* derived types had been 
introduced into the language before the COMPLEX data type had been 
added, then it would have been more straightforward to have defined 
an intrinsic derived type to handle complex operations.  Then a 
separate syntax would not have been developed for declarations, 
assignments, access to the individual real and imaginary components, 
etc., the standard derived type operations could have been used for 
all of those situations.  The same goes for OPEN statements.  If the 
ideas of positional and keyword arguments, optional arguments with 
defaults, etc. had been introduced earlier into the language, then 
OPEN would probably have been implemented as an intrinsic subroutine 
rather than as a separate statement.

In the case of COMPLEX, there may be some advantages to overlaying 
the derived type syntax on top of the existing f77 style syntax.  
This would allow, for example separate access to the real or 
imaginary components of both scalar and array variables.  I don't 
think there are many advantages to changing OPEN, and, except for 
the fact that it seems rather trivial to do so, it is more of an 
esthetic issue than a practical one.

$.02 -Ron Shepard

Ron Shepard <ron-shepard@NOSPAM.comcast.net> wrote:

> In the case of COMPLEX, there may be some advantages to overlaying 
> the derived type syntax on top of the existing f77 style syntax.  
> This would allow, for example separate access to the real or 
> imaginary components of both scalar and array variables.

Agree. And as I mentioned in another posting in this thread, there is an
active proposal for that.

A proposed modification would change complex to actually *BE* an
intrinsic derived type, but that turns out to have ramifications all
over the place, as intrinsic vs derived is currently a pretty
fundamental distinction, with more subtle consequences than you'd think.
In the longer term, I see some benefit in a different classification of
types, with intrinsic vs user-defined on one axis, and atomic vs
composite (or probably some better terms than that) on another. But my
personal opinion is that this would be far too big a change for what is
targetted as a minor revision. Lots of places in the standard would be
affected, and some of the effects are subtle.

Just adding a small piece of syntax to denote the real and imaginary
parts of a complex is, in my opinion, a much smaller change and one I
personally favor. I *think* it will make it in the next revision.

-- 
Richard Maine                     | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov            |       -- Mark Twain

James Giles wrote in message ...
>Richard Maine wrote:
>...
>> Well... though I'll admit to also occasionally wishing that character
>> n of a character string could be accessed as b(n),
>>
>> 1) I think it gives ride to syntactic ambiguity when you add arrays of
>> strings.
>
>Actually not.  The ambiguity is that string(n) is assumed to
>be a function reference

No more than array(n) is assumed to be a function reference.

John Harper wrote in message <1129774192.14947@bats.mcs.vuw.ac.nz>...
>Three cases where analogous things have different syntax are
>
>(1) Element n of a rank 1 array a is a(n)
>but element n of a character string b is b(n:n)

And how would you distinguish between b(n) of string array b
and b(n:n) of string b? if both were written as b(n) ?

>(2) An implied-do loop with stride 1 needs (... , i=m,n)
>but a FORALL statement with stride 1 needs FORALL(i=m:n) ...

strange.

>(3) In most declarations :: may appear between type and variable-name,
>and it must in certain circumstances, but :: must not appear between
>FUNCTION and function-name nor between SUBROUTINE and subroutine-name,

Has never required :: there. Doesn't require them, and does not
make sense to have any there.

>and one must say RESULT(x) not RESULT::x or RESULT x

RESULT (X) is not a declaration of X; use of :: is inappropriate.
The declaration of X may require use of ::

>John Harper

Hello,

robin wrote:
> James Giles wrote in message ...
> 
>>Richard Maine wrote:
>>...
>>
>>>Well... though I'll admit to also occasionally wishing that character
>>>n of a character string could be accessed as b(n),
>>>
>>>1) I think it gives ride to syntactic ambiguity when you add arrays of
>>>strings.
>>
>>Actually not.  The ambiguity is that string(n) is assumed to
>>be a function reference
> 
> 
> No more than array(n) is assumed to be a function reference.

Given

character :: string

what is

string( 1) ?

-- 
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

In article <VYX5f.23787$U51.9871@news-server.bigpond.net.au>,
robin <robin_v@bigpond.com> wrote:
>John Harper wrote in message <1129774192.14947@bats.mcs.vuw.ac.nz>...
>>Three cases where analogous things have different syntax are
>>
>>(1) Element n of a rank 1 array a is a(n)
>>but element n of a character string b is b(n:n)
>
>And how would you distinguish between b(n) of string array b
>and b(n:n) of string b? if both were written as b(n) ?

By their declarations. Character statements would disambiguate, e.g. 
   character b1*8, b2(6)*8
would mean that b1(m) was character m of b1, b2(m) was element m of b2,
and b2(m)(n) was character n of element m of b2, as b2(m)(n:n) is.

You could of course avoid character statements, e.g. with
   implicit character*8 (b)
but any character array would still need to be declared as such, e.g.
   dimension b2(6) 
and anything starting with b but not an array would be a scalar.

There could be a character*8 function b2 of an integer variable, but
that would be disambiguated by its function declaration, unless b2 were 
a statement function. I hadn't thought of that, but I now suspect the 
f77 writers did. And every Fortran standard will have to follow suit 
until after the last statement function has vanished from legacy code. 
Given that some f66 code is still around, that will probably be after 
my heirs get their legacies:-)

John Harper, School of Mathematics, Statistics and Computer Science, 
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

Dan Nagle wrote in message <5zY5f.10498$nk2.2306@trnddc07>...
>Hello,
>
>robin wrote:
>> James Giles wrote in message ...
>>
>>>Richard Maine wrote:
>>>...
>>>
>>>>Well... though I'll admit to also occasionally wishing that character
>>>>n of a character string could be accessed as b(n),
>>>>
>>>>1) I think it gives ride to syntactic ambiguity when you add arrays of
>>>>strings.
>>>
>>>Actually not.  The ambiguity is that string(n) is assumed to
>>>be a function reference
>>
>> No more than array(n) is assumed to be a function reference.
>
>Given
>
>character :: string
>
>what is
>
>string( 1) ?


Given
    real :: x
what is
    x(1) ?

>--
>Cheers!
>
>Dan Nagle

Hello,

robin wrote:
> Dan Nagle wrote in message <5zY5f.10498$nk2.2306@trnddc07>...

<snip>

>>>>Actually not.  The ambiguity is that string(n) is assumed to
>>>>be a function reference
>>>
>>>No more than array(n) is assumed to be a function reference.
>>
>>Given
>>
>>character :: string
>>
>>what is
>>
>>string( 1) ?
> 
> 
> 
> Given
>     real :: x
> what is
>     x(1) ?

Well, for one thing, it's not a substring!


-- 
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

robin wrote:
| Dan Nagle wrote in message <5zY5f.10498$nk2.2306@trnddc07>...
|| Hello,
|| 
|| robin wrote:
||| James Giles wrote in message ...
||| 
|||| Richard Maine wrote:
|||| ...
|||| 
||||| Well... though I'll admit to also occasionally wishing that character
||||| n of a character string could be accessed as b(n),
||||| 
||||| 1) I think it gives ride to syntactic ambiguity when you add arrays of
||||| strings.
|||| 
|||| Actually not.  The ambiguity is that string(n) is assumed to
|||| be a function reference
||| 
||| No more than array(n) is assumed to be a function reference.
|| 
|| Given
|| 
|| character :: string
|| 
|| what is
|| 
|| string( 1) ?
| 
| 
| Given
|     real :: x
| what is
|     x(1) ?

A syntax error.

However, as Giles pointed out, given character:: string, reference 
to string(1) is NOT a syntax error per se (without implicit none). 

I find it a silly inconsistence, but I doubt that there exist 
codes "in the wild" that depend on the feature. But I wouldn't
swear it of course.

-- 
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

In article <3s3i0hFlua2fU1@individual.net>,
 "Jugoslav Dujic" <jdujic@yahoo.com> wrote:

> | 
> | Given
> |     real :: x
> | what is
> |     x(1) ?
> 
> A syntax error.
> 
> However, as Giles pointed out, given character:: string, reference 
> to string(1) is NOT a syntax error per se (without implicit none). 

I still do not understand what you guys are talking about with 
IMPLICIT NONE.  The function type is declared explicitly, so 
IMPLICIT NONE has no effect at all on the legality or the symantics.

function x(i)
   real :: x
   integer :: i
   x = i*i
end function x
program xxx
   implicit none
   real :: x
   write(*,*) x(1)
end program xxx

As far as I know, the above is a correct, legal, valid, program, and 
it does not matter whether IMPLICIT NONE is included or not.  If you 
change the function to some character function,

function x(i)
   character :: x
   integer :: i
   x = char(ichar('A')+i)
end function x
program xxx
   implicit none
   character :: x
   write(*,*) x(1)
end program xxx

then I think it is still correct, legal, and valid either with or 
without IMPLICIT NONE.

Since several posts have now been made with the idea that IMPLICIT 
NONE changes the symantics, or makes something legal that would not 
otherwise be legal (or visa versa), I conclude that there is simply 
something that either my eye, or my compilers, is missing.

$.02 -Ron Shepard

Jugoslav Dujic wrote:
> robin wrote:
> | Dan Nagle wrote in message <5zY5f.10498$nk2.2306@trnddc07>...
> || Hello,
> || 
> || robin wrote:
> ||| James Giles wrote in message ...
> ||| 
> |||| Richard Maine wrote:
> |||| ...
> |||| 
> ||||| Well... though I'll admit to also occasionally wishing that character
> ||||| n of a character string could be accessed as b(n),
> ||||| 
> ||||| 1) I think it gives ride to syntactic ambiguity when you add arrays of
> ||||| strings.
> |||| 
> |||| Actually not.  The ambiguity is that string(n) is assumed to
> |||| be a function reference
> ||| 
> ||| No more than array(n) is assumed to be a function reference.
> || 
> || Given
> || 
> || character :: string
> || 
> || what is
> || 
> || string( 1) ?
> | 
> | 
> | Given
> |     real :: x
> | what is
> |     x(1) ?
> 
> A syntax error.
Can't it be a function reference?
       print *, x(1)
looks OK to me,
x(1) = 0
is an error, because you can't have a function on the left.
But,
x(L) = 0
might be a statement function definition, depending on where
it's at.

I think string(1) has the same feature/problem (unless I've
lost track of this thread).

Dick Hendrickson
> 
> However, as Giles pointed out, given character:: string, reference 
> to string(1) is NOT a syntax error per se (without implicit none). 
> 
> I find it a silly inconsistence, but I doubt that there exist 
> codes "in the wild" that depend on the feature. But I wouldn't
> swear it of course.
> 

Hello,

Ron Shepard wrote:

<snip>

> I still do not understand what you guys are talking about with 
> IMPLICIT NONE.  The function type is declared explicitly, so 
> IMPLICIT NONE has no effect at all on the legality or the symantics.

AIUI, here's the root:

If I see name(...), and name has been given the array attribute,
I know I have a array reference.

If I see name(...), and name has not been given the array attribute,
I know I have a function reference.

If character :: string is allowed, with (i) as
a valid substring selector, the simple binary analysis above
fails.  That is, when (i) is not an array element selector,
it might be a function argument list, or it might be
a substring selector.

This is what some have called "ambiguous" although one might devise
rules to disambiguate.

That is, if I've been following the discussion correctly.

<snip examples>

> $.02 -Ron Shepard

Personally, I don't see much value in treating strings
as character arrays.  Others disagree.  YMMV

-- 
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

Ron Shepard wrote:
| In article <3s3i0hFlua2fU1@individual.net>,
|  "Jugoslav Dujic" <jdujic@yahoo.com> wrote:
| 
||| 
||| Given
|||     real :: x
||| what is
|||     x(1) ?
|| 
|| A syntax error.
|| 
|| However, as Giles pointed out, given character:: string, reference
|| to string(1) is NOT a syntax error per se (without implicit none).
| 
| I still do not understand what you guys are talking about with
| IMPLICIT NONE.  The function type is declared explicitly, so
| IMPLICIT NONE has no effect at all on the legality or the symantics.
| 
| function x(i)
|    real :: x
|    integer :: i
|    x = i*i
| end function x
| program xxx
|    implicit none
|    real :: x
|    write(*,*) x(1)
| end program xxx
| As far as I know, the above is a correct, legal, valid, program, and
| it does not matter whether IMPLICIT NONE is included or not.  If you
| change the function to some character function,

My bad (again). I wrongly thought that in F9x,

real :: x

means "x is a real scalar variable", and that one needs 

real, external :: x

to declare a "real external function". Since I'm wrong, I'll tweak
your examples a bit below. Now, initialization makes it clear that
we're declaring a scalar *variable*.
 
 function x(i)
   character :: x
   integer :: i
   x = char(ichar('A')+i)
end function x
program xxx
   implicit none
   character :: x = "B"
   write(*,*) x(1)
end program xxx

function x(i)
   real :: x
   integer :: i
   x = i*i
end function x
program xxx
   implicit none
   real :: x = 1
   write(*,*) x(1)
end program xxx

| Since several posts have now been made with the idea that IMPLICIT
| NONE changes the symantics, or makes something legal that would not
| otherwise be legal (or visa versa), I conclude that there is simply
| something that either my eye, or my compilers, is missing.

There's something in your words indeed, namely that we're probably
discussing a strawman. 


-- 
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Ron Shepard <ron-shepard@NOSPAM.comcast.net> wrote:

> In article <3s3i0hFlua2fU1@individual.net>,
>  "Jugoslav Dujic" <jdujic@yahoo.com> wrote:
> 
> > | 
> > | Given
> > |     real :: x
> > | what is
> > |     x(1) ?
> > 
> > A syntax error.

No it isn't. It is a function reference. I suggest trying it with an
actual; compiler if you (well, Jugoslav) don't believe me. *ANY*
compiler.

> > However, as Giles pointed out, given character:: string, reference 
> > to string(1) is NOT a syntax error per se (without implicit none). 
> 
> I still do not understand what you guys are talking about with 
> IMPLICIT NONE.  The function type is declared explicitly, so 
> IMPLICIT NONE has no effect at all on the legality or the symantics.
....
> Since several posts have now been made with the idea that IMPLICIT 
> NONE changes the symantics, or makes something legal that would not 
> otherwise be legal (or visa versa), I conclude that there is simply 
> something that either my eye, or my compilers, is missing.

I don't think so. I think that all the posters alluding to implicit none
are just wrong and that you have it exactly right.

I have at one point seen a proposal (or maybe even an actual compiler
option) to require that the external attribute be declared explicitly,
but no such thing is part of the standard (or even common as an
extension).

At times I bemoan the distributed way in which Fortran specified
attributes. Even with the attribute-oriented form of declarations, there
is no way to specify that a given statement declares all the attributes
of an entity and that there can't be any other elsewhere. But, whether I
like it or not, the language does allow such distributed specification.
AT times, this makes it hard to describe simple things. For example, you
often see people exlaining that a statement like

  real :: x

declares that x is a real scalar variable. In fact, it declares no such
thing. All it declares is that x, whatever it is, has type real. It need
not be a scalar or a variable. Indeed, there is one quirky case where it
doesn't even have to be real (where x is an intrinsic generic; I suppose
the name x isn't a good example for that, but, say "character :: sin" is
mostly a quirky no-op).

-- 
Richard Maine                     | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov            |       -- Mark Twain

Richard E Maine wrote:
| Ron Shepard <ron-shepard@NOSPAM.comcast.net> wrote:
| 
|| In article <3s3i0hFlua2fU1@individual.net>,
||  "Jugoslav Dujic" <jdujic@yahoo.com> wrote:
|| 
|||| 
|||| Given
||||     real :: x
|||| what is
||||     x(1) ?
||| 
||| A syntax error.
| 
| No it isn't. It is a function reference. I suggest trying it with an
| actual; compiler if you (well, Jugoslav) don't believe me. *ANY*
| compiler.

My bad (as usual :o) ). I thought that in F9x

real::    x

declares a real scalar variable, and that I need at least


real, external::    x

to declare a real external function. Obviously, wrong (or, to
be more precise, wishful thinking).

To add some salt, initialization or save attribute do make the
intent more explicit.
-- 
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Jugoslav Dujic <jdujic@yahoo.com> wrote:

> I thought that in F9x
> 
> real::    x
> 
> declares a real scalar variable, and that I need at least
> 
> 
> real, external::    x
> 
> to declare a real external function. Obviously, wrong (or, to
> be more precise, wishful thinking).

I share your wish, but.... :-(

-- 
Richard Maine                     | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov            |       -- Mark Twain

Ron Shepard wrote:
> In article <3s3i0hFlua2fU1@individual.net>,
>  "Jugoslav Dujic" <jdujic@yahoo.com> wrote:
>
>>>
>>> Given
>>>     real :: x
>>> what is
>>>     x(1) ?
>>
>> A syntax error.
>>
>> However, as Giles pointed out, given character:: string, reference
>> to string(1) is NOT a syntax error per se (without implicit none).
>
> I still do not understand what you guys are talking about with
> IMPLICIT NONE.  The function type is declared explicitly, so
> IMPLICIT NONE has no effect at all on the legality or the symantics.

That's "semantics".

But, we're tal;king about a hypothetical path the language
*could* have taken.  I still thing IMPLICIT NONE should
*require* that external functions be declared as EXTERNAL.
If not, you should not be allowed to reference it as a function.
IMPLICIT NONE wasn't in the F77 standard, so they could
have added it and made it's meaning anything they wanted.

In the case under discussion:

   Implicit none
   Character*50 f, str
   External f
   ...
   str = f(40)  ! references function F with an argument of 40
   Write(*,*) str(40)  ! writes out the fortieth character of STR

That *could* very well have been the rule.  That probably
*should* have been the rule.  It's water under the bridge
(and already long since found the sea, and re-evaporated,
and probably in the amazon by now).  The only reason
I mentioned it in the first place was the subtle point that
str(40) is illegal in Fortran *not* because of some possible
ambiguity with character arrays, but because of the rule
about function references.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

James Giles <jamesgiles@worldnet.att.net> wrote:

> But, we're tal;king about a hypothetical path the language
> *could* have taken.

Oh. I see. That wasn't clear to me from the original mention. (I don't
appear to have been alone in missing this intended meaning).

>  I still thing IMPLICIT NONE should
> *require* that external functions be declared as EXTERNAL.

As it happens I agree with you, but, as you say...

> It's water under the bridge

-- 
Richard Maine                     | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov            |       -- Mark Twain

Richard E Maine wrote:
> James Giles <jamesgiles@worldnet.att.net> wrote:
>
>> But, we're tal;king about a hypothetical path the language
>> *could* have taken.
>
> Oh. I see. That wasn't clear to me from the original mention. (I don't
> appear to have been alone in missing this intended meaning).

Well, actually I wasn't originally talking about a hypothetical
development of the language, but merely responding to the
basic issue of where the ambiguity lies with respect to the
desire to omit the colon for single character substrings.
The thread subsequently developed into a hypothetical
discussion of what the language *could* have done.  In that
context, the language *could* have done a lot of things.  I've
just expounded the nature of some of the things I'd like to
have seen.  In addition, I'd like for character assignment
*not* to pad with spaces, I'd like for character assignment
*not* to silently truncate, I'd like for character compares
*not* to extend with blanks, etc.  So:

   Character(10) :: str1, str2
   ...
   str1 = "abc"  ! LEN(str1) is now three, no blanks
   str2 = "abc " ! LEN(str2) is four, with the single blank
   write(*,*) str1<str2  ! outputs .true. since a short string
                         ! is less than a longer one
   str2 = str1 // " xyz"  ! LEN(str2) is now seven
   str1 = str2 // "lmno" ! halts with run-time error, str1
                         ! can't hold eleven characters
   ... and so on ...

Quite a number of the most frequently asked questions about
strings would be settled if these had been the rules.  It still
permits static allocation of character variables, which was
an F77 requirement.  Again: water under the bridge.  Other
languages still have time to learn from F77's mistakes though.
The same water passes under lots of bridges.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare