On Nov 24, 2004, at 8:48 AM, Craig Dedo wrote:

>    Can anyone suggest reasons why the standard prohibits direct access
> on internal files?  From an I/O standp[oint, it appears to me that a
> character array of 1000 elements is very much the same thing as a disk
> file with 1000 records.

Possibly because

1. It doesn't add any utility. If you want to write to the 42nd element
of this array, you can do that anyway using the array element as the
internal file.  I can't think of a single thing this would add in terms
of utility in exchange for the cost. Not that the cost would probably
be very high, but it would be >0, and I'd hope to see at least *SOME*
benefit to outweigh it.

2. There isn't a way to explicitly open internal files. That is
inherent to them and would be a *BIG* deal to change. OPEN is where one
specifies nondefault things like direct access.  Ok, one could have the
implied open depend on whether rec= was specified in the read or write;
that's probably doable, but is a complication.  See point 1 about
expecting at least some benefit for this complication.

>    Similarly, can anyone suggest reasons why the standard prohibits
> unformatted I/O on internal files?

That one is much simpler.

1. Internal files are characters.  I/O to character devices is
formatted, by definition. It makes exactly as much sense to do
unformatted I/O for an internal file as it does to do unformatted I/O
with a printer, terminal screen, etc.  The standard doesn't allow
either one. There exist compilers that allow you to do unformatted I/O
to a formatted file. That is a compiler extension. I don't personally
see that feature as one likely to become standardized, though you can
presumably guess such things as well as I can. I have an even harder
time imagining that the special case of internal I/O would be allowed
when the more general case was not; if it were to be done (which I
doubt in either case), I'd assume it would make more sense to do the
general case.

2. Same as the previous point 2. There is no OPEN statement to specify
this, so it would have to be implicit in the read or write.  Ok, here
there is at least some benefit, but still.

3. Further to point 2, implicit specification of this in a read/write
would make for nasty errors. Omitting a format specification is a
reasonably common error. If an extension like this were adopted, that
error would just result in unformatted I/O (which would pretty much
never give anything even vaguely close to what the user intended to do
with formatted I/O).

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