Somewhat belated rely as I have been on vacation for 3 weeks. I see 
that others have addressed most of the comments I would have made. I 
have just a few additional side comments.

On Jul 6, 2005, at 1:23 PM, Clive Page wrote:

> I had not appreciated the substantial differences between formatted 
> and unformatted stream I/O, and had only looked properly at the 
> sections of the Standard describing the former.

Ouch! Then no wonder you were confused. They are indeed very different. 
Furthermore, unformatted is *FAR* simpler. If you had to concentrate 
only on one of them I'd sure recommend looking at unformatted instead 
of formatted.

In fact, my original proposal for stream I/O didn't include formatted 
because I was trying to keep things simple. Formatted streams are 
substantially more complicated and yet don't add anything that I regard 
as critically new, so I figured that omitting them would help the 
cost/benefit tradeoff. But the gist of the responses to my proposal was 
that "everyone" liked the idea, but many people also wanted formatted 
capability, so it got added. Almost all of the subsequent work on the 
subject was on formatted... because it had all the complications that 
needed work. At times I wish I had resisted the request to add 
formatted....

In regards to the differences:

A formatted stream file is really the same thing as a sequential text 
file. It is perhaps a bit of a misnomer to refer to it as a kind of 
file at all (but the standard does and that's probably my fault at 
least in part). It is a different way to access the same kind of file. 
The form of access is more convenient in some situations, but I don't 
personally regard formatted streams as a critical new feature.

In particular, a formatted stream file *IS* also a record file. It 
comes complete with all the properties that record files have - whether 
you choose to call these "shackles" on not. I personally happen to 
think of record files as a case of the operating system providing 
important additional support that would otherwise have to be done by 
the user. I don't view the fact that most current operating systems 
omit record management support to be an improvement. But I digress... I 
think that many of the restrictions and oddities of formatted stream 
access can be best understood through recognizing that this really is a 
record file.

In that regard, I have not time to do a detailed review of the web page 
you wrote up, but I found one point in it to be seriously misleading. 
No, formatted stream files (aka formatted sequential files) do *NOT* 
have the structure of a line of text followed by a delimiter. If you 
try to think of that as their basic definition, then you will probably 
get confused by many things. Their structure is just a line of text in 
a record. The record is defined by the processor (compiler). In that 
regard, they are just as system-dependent as unformatted files. It just 
happens that essentially all systems define and support a suitable text 
file structure, which Fortran implementations naturally use. (The 
Fortran standard doesn't require that Fortran sequential formatted 
files be compatible with such things as text editors or anything else 
on the system, but the market does require it).

With formatted stream access, the newline character is used in the 
output data to *REPRESENT* the end of a record. This does not in any 
way imply that records are actually stored in such a manner. If I 
recall correctly, the same is true of C. The possible translations 
between this representation and the actual file structure relate to 
some of the restrictions.

Unformatted streams provide capability that is fundamentally new and 
was really *VERY* painful to do portably and within the context of 
previous Fortran standards. Trust me on that :-(. They are also pretty 
simple.

> The whole point of stream I/O, I thought, was that for the first time 
> it frees the Fortran programmer from the shackles of record-based I/O.

I would also say that this majorly mischaracterized the main 
motivations for adding stream I/O. Well, I guess you've got in in other 
material, but with a different emphasis than I would use. I consider 
the primary motivation for unformatted stream access to be 
interoperability (and formatted stream was just an "add-on" in my view, 
as I mention above). In fact, stream I/O originally was introduced as 
part of the C interop stuff, though it has subsequently been identified 
as a separate feature in its own right. You need unformatted stream to 
deal with independently defined file formats (such as graphics image 
files and many others). Prior to stream I/O, there was no way to do 
this that was sanctioned by the standard.

"Faking it" with direct access files often worked, but that involved 
making assumptions about implementation details that were not 
guaranteed by the standard (and the assumptions were not always 
correct). It was also quite a bit of work and had multiple 
complications. It was one area where I regularly recommended that 
people go ahead and use vendor extensions.

The lack of record structure is more of a side matter to me. That's a 
consequence of the interop needs rather than a basic requirement on its 
own.

As with formatted streams, there are times when unformatted streams are 
more convenient, even independent of interop issues. This is 
particularly so when you need random access, but don't want to be 
shackled with a fixed record size (the limitation to fixed record size 
*IS* something I regard as a shackle, though one I understand the 
reasons for). Even if you do need a record structure, if you need both 
random access and variable record size, it is usually far easier to do 
your own record management starting from unformatted stream files than 
to hack up something from what was available in previous Fortran 
standards.

But if variable-size random access records were the main goal, I think 
that could have been more directly addressed. I view the interop issue 
as the primary goal, with the other benefits as handy "free" extras. 
Admittedly, the separation here isn't 100%; sometimes interoperable 
files have requirements for random access to variable-sized chunks of 
data, so it is not a coincidence that you end up with ways to do that.

-- 
Richard Maine                |  Good judgment comes from experience;
[log in to unmask]       |  experience comes from bad judgment.
                             |        -- Mark Twain