Home > Archive > Fortran > February 2007 > Most elegant way to read to allocatable array?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Most elegant way to read to allocatable array?
|
|
| yair999@gmail.com 2007-01-18, 7:06 pm |
| Hi,
Suppose I have an input record as follows:
5 1. 2. 3. 4. 5.
Where the first integer is in fact the number of following constants.
Is there a more elegant way to read the constants into an allocatable
array using list directed sequential read than the following?
real, allocatable :: A(:)
open (5,file='kuku.txtx')
read (5,*) num
allocate (A(num))
backspace 5
read (5,*) num,A
end
| |
| Beliavsky 2007-01-18, 7:06 pm |
|
yair999@gmail.com wrote:
> Hi,
>
> Suppose I have an input record as follows:
>
> 5 1. 2. 3. 4. 5.
>
> Where the first integer is in fact the number of following constants.
>
> Is there a more elegant way to read the constants into an allocatable
> array using list directed sequential read than the following?
I would READ the line into a string and READ the string twice, instead
of using BACKSPACE. I don't know if it is more elegant, but if the
second READ fails, I can write an error message
"could not read 5 numbers from " <some string>
I recommend against connecting unit 5 to an external file. God intended
it for standard input.
> real, allocatable :: A(:)
> open (5,file='kuku.txtx')
> read (5,*) num
> allocate (A(num))
> backspace 5
> read (5,*) num,A
> end
| |
| Thomas Koenig 2007-01-18, 7:06 pm |
| yair999@gmail.com <yair999@gmail.com> wrote:
>5 1. 2. 3. 4. 5.
>Is there a more elegant way to read the constants into an allocatable
>array using list directed sequential read than the following?
>
>real, allocatable :: A(:)
>open (5,file='kuku.txtx')
>read (5,*) num
>allocate (A(num))
>backspace 5
>read (5,*) num,A
>end
Unfortunately, advance="no" won't work with list-directed I/O.
Depending on how your input file was created, the BACKSPACE is
also on shaky ground, see 9.5.1 of the F95 draft:
# Backspacing over records written using list-directed or
# namelist formatting is prohibited.
Also, the internal read might well continue into the next record.
Can you assume a maximum length of the input line? Then it would
be best to read in the whole line and split it up using INDEX and
internal read.
| |
| Richard Maine 2007-01-18, 7:06 pm |
| On Thu, 18 Jan 2007 08:30:47 -0800, Beliavsky wrote
(in article <1169137839.041601.174390@l53g2000cwa.googlegroups.com> ):
> yair999@gmail.com wrote:
>
> I would READ the line into a string and READ the string twice, instead
> of using BACKSPACE.
I agree. There has been recent discussion here of the problems that backspace
has in some contexts; I recommend avoiding it where feasible. It is feasible
to avoid it here.
I was about to mention list-directed I/O as an alternative to the internal
read, but then I recalled that non-advancing I/O isn't allowed with
list-directed. Hmm. I understand why that restriction exists for output, but
the reason seems weaker for input. I suppose I can see a hint of a reason,
but it seems weak.
As another alternative.... I'm thinking about the fact that you'd be needing
to pre-size a suitable string, which only works if you can give a prior limit
on how long the line might be. If this is all on one line, odds are that the
number of elements involved isn't huge so that space probably isn't the
reason for wanting the array allocatable. I'm guessing that you want the
array allocatable because it is "cleaner" to subsequently use the whole array
without having to take a slice of it. In that case, one alternative is to
pre-size a temporary array and read into it. Then allocate and copy to the
allocatable array. Pre-sizing the temporary array is no more restrictive than
pre-sizing the temporary string to use with internal I/O. Something like
real :: temp(100) !-- or choose some other suitable max size.
real, allocatable :: a(:)
integer :: n, i, lun
...
read(lun,*) n, (temp(i),i=1,min(n,size(temp)))
if (n>size(temp) ...! Oops
allocate(a(n))
a = temp(1:n)
If n might plausibly be large enough to make static pre-allocation of a
temporary array or string awkward, then life gets a bit harder. Not
incredibly hard. There are ways, but it is harder. Not worth going into here
unless you have that problem.
--
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
| |
| yair999@gmail.com 2007-01-18, 7:06 pm |
|
Thomas Koenig wrote:
> Depending on how your input file was created, the BACKSPACE is
> also on shaky ground, see 9.5.1 of the F95 draft:
>
> # Backspacing over records written using list-directed or
> # namelist formatting is prohibited.
My input file is created manually using a text editor, so I guess
there's no problem there(?)
| |
| yair999@gmail.com 2007-01-18, 7:06 pm |
|
Beliavsky wrote:
> I would READ the line into a string and READ the string twice, instead
> of using BACKSPACE. I don't know if it is more elegant, but if the
> second READ fails, I can write an error message
>
> "could not read 5 numbers from " <some string>
Well, that's possible but not more elegant to my taste... :)
| |
| yair999@gmail.com 2007-01-18, 7:06 pm |
|
Richard Maine wrote:
> As another alternative.... I'm thinking about the fact that you'd be needing
> to pre-size a suitable string, which only works if you can give a prior limit
> on how long the line might be. If this is all on one line, odds are that the
> number of elements involved isn't huge so that space probably isn't the
> reason for wanting the array allocatable. I'm guessing that you want the
> array allocatable because it is "cleaner" to subsequently use the whole array
> without having to take a slice of it.
That assumption is correct.
In that case, one alternative is to
> pre-size a temporary array and read into it. Then allocate and copy to the
> allocatable array. Pre-sizing the temporary array is no more restrictive than
> pre-sizing the temporary string to use with internal I/O. Something like
> real :: temp(100) !-- or choose some other suitable max size.
> real, allocatable :: a(:)
> integer :: n, i, lun
> ...
> read(lun,*) n, (temp(i),i=1,min(n,size(temp)))
> if (n>size(temp) ...! Oops
> allocate(a(n))
> a = temp(1:n)
well, the original prog was kind of:
real :: A(100) !-- or choose some other suitable max size.
integer :: n, i, lun
...
read(lun,*) n, (A(i),i=1,min(n,size(A)))
if (n>size(A) ...! Oops
and I just worked with A(1:n)
Your proposal may be considered slightly more elegant.
Yet I was hoping for something MORE elegant :).
Still I do not see why backspace should be avoided in THIS case, let's
say on lun /= 5,6,7 (?)
| |
| glen herrmannsfeldt 2007-01-18, 7:06 pm |
| Beliavsky <beliavsky@aol.com> wrote:
> yair999@gmail.com wrote:
[color=darkred]
[color=darkred]
(previously snipped example using BACKSPACE)
[color=darkred]
> I would READ the line into a string and READ the string twice, instead
> of using BACKSPACE. I don't know if it is more elegant, but if the
> second READ fails, I can write an error message
> "could not read 5 numbers from " <some string>
That is just the problem. Now he is reading five, but next he
will want to read more, maybe thousands or millions. With list directed
read it will automatically read the appropriate number of lines.
Reading the first into a string, extracting the number, allocating
the array, reading the rest of the string into the array, and then
continuing on with a list directed read of the rest of the file seems
a little indirect, but probably the right way to do it.
-- glen
| |
| glen herrmannsfeldt 2007-01-18, 7:06 pm |
| Thomas Koenig <Thomas.Koenig@online.de> wrote:
> Unfortunately, advance="no" won't work with list-directed I/O.
> Depending on how your input file was created, the BACKSPACE is
> also on shaky ground, see 9.5.1 of the F95 draft:
> # Backspacing over records written using list-directed or
> # namelist formatting is prohibited.
Well, the problem is that in general you don't know how many
records were read. In this case, the first READ reads only one
value, though it may be more than one record until it gets to that
value. It shouldn't read any more records after that.
> Also, the internal read might well continue into the next record.
> Can you assume a maximum length of the input line? Then it would
> be best to read in the whole line and split it up using INDEX and
> internal read.
I am guessing that he wants to read many numbers on many lines.
The example only has one line.
-- glen
| |
| Richard Maine 2007-01-18, 7:06 pm |
| On Thu, 18 Jan 2007 10:21:59 -0800, yair999@gmail.com wrote
(in article <1169144519.483587.251750@38g2000cwa.googlegroups.com> ):
> say on lun /= 5,6,7 (?)
It's just a guideline - not a hard rule. But the reason for the guideline is
that backspace won't work in all situations... and in other situations it can
work but have unbelievably slow performance. In the old days of big machines
and tape drives, I have seen an operator abort a job and refuse to run it
again until it was recoded to use a different method... that did not involve
using backspace-read-backspace-backspace-read, etc to read all the way
through a large tape backwards; it was putting excessive wear on the tape
drive and/or tapes.
Sort of related - I didn't mention it at the time, but I second Beliavsky's
advice to avoid opening units 5 and 6 (or any unit numbers less than 10, but
5 and 6 are the "worst"). Those are exactly the unit numbers *MOST* likely to
have problems. They are often special-cased in several ways.
In particular, if you ever type input into the program interactively (usually
on unit 5), the backspace is unlikely to work. Depends on the particular
compiler, but it is problematic. Likewise, if you ever use some other program
to prepare the input file and pipe it to this program, it is unlikely to
work.
So you seem to have it backwards - backspace is more likely to be ok on units
other than 5 and 6.
--
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 Maine 2007-01-18, 7:06 pm |
| On Thu, 18 Jan 2007 10:50:07 -0800, glen herrmannsfeldt wrote
(in article <eoofgv$ij5$4@naig.caltech.edu> ):
> That is just the problem. Now he is reading five, but next he
> will want to read more, maybe thousands or millions. With list directed
> read it will automatically read the appropriate number of lines.
> Reading the first into a string, extracting the number, allocating
> the array, reading the rest of the string into the array, and then
> continuing on with a list directed read of the rest of the file seems
> a little indirect, but probably the right way to do it.
Perhaps the problem statement was imprecise, but the "appropriate number of
lines" part does not match the problem as stated. It said "I have *AN*
[emphasis mine] input record." Depending on context, that could literally
mean that the whole thing would always be in one record, even if it had
thousands or millions of elements. In that case, reading first into a string
just moves the problem instead of fixing it; you then have to worry about
sizing the string.
--
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 Maine 2007-01-18, 7:06 pm |
| On Thu, 18 Jan 2007 10:55:20 -0800, glen herrmannsfeldt wrote
(in article <eoofqo$ij5$5@naig.caltech.edu> ):
> I am guessing that he wants to read many numbers on many lines.
That is directly contradicted by what the OP said in the initial post. It is
certainly possible that what he said wasn't what he meant, but do note that
the problem statement was explicit on the point.
--
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
| |
| glen herrmannsfeldt 2007-01-18, 7:06 pm |
| yair999@gmail.com <yair999@gmail.com> wrote:
> Still I do not see why backspace should be avoided in THIS case, let's
> say on lun /= 5,6,7 (?)
The input could be a non-s able device, a pipe or terminal
for example.
I did once, on TOPS-10, compile a Fortran program directly
from the terminal. No mistakes are allowed, as backspace (character)
doesn't work.
-- glen
| |
| yair999@gmail.com 2007-01-18, 7:06 pm |
|
Richard Maine wrote:
> On Thu, 18 Jan 2007 10:55:20 -0800, glen herrmannsfeldt wrote
> (in article <eoofqo$ij5$5@naig.caltech.edu> ):
>
>
> That is directly contradicted by what the OP said in the initial post. It is
> certainly possible that what he said wasn't what he meant, but do note that
> the problem statement was explicit on the point.
Well, as a matter of fact I have just FOUR such lines... :)
(and there will never be even tens of such lines in THIS prog)
| |
| Richard E Maine 2007-01-18, 7:06 pm |
| glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
> I did once, on TOPS-10, compile a Fortran program directly
> from the terminal. No mistakes are allowed, as backspace (character)
> doesn't work.
Ouch. I've never done that one. But I have more than once been in a
position where I was editing (small) critical system configuration files
using the unix cat or echo command, or something at that level. That was
a result of having an error in the file, preventing the system from
fully booting. I could boot into a severely limited environment with
almost no commands available. Booting up a separate diagnostic/repair
system would have taken literally several hours (this was some old Sun
systems, where the procedure to boot from the recovery media that I had
was an incredbly painful multi-step process - much better now).
--
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
| |
| glen herrmannsfeldt 2007-01-18, 7:06 pm |
| Richard E Maine <nospam@see.signature> wrote:
> glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
[color=darkred]
> Ouch. I've never done that one.
It was a very small program, and it took a few tries.
-- glen
| |
| glen herrmannsfeldt 2007-01-18, 7:06 pm |
| Richard Maine <nospam@see.signature> wrote:
(snip on reading data into an array)
> Perhaps the problem statement was imprecise, but the "appropriate number of
> lines" part does not match the problem as stated. It said "I have *AN*
> [emphasis mine] input record." Depending on context, that could literally
> mean that the whole thing would always be in one record, even if it had
> thousands or millions of elements.
Even if that is currently the goal, problems tend to get bigger with time.
If it really is a small number, then read it into a numeric array,
allocate another array of the appropriate size, and copy.
> In that case, reading first into a string just moves the problem
> instead of fixing it; you then have to worry about sizing the string.
Yes, if you can size the character array, you can size a temporary
numeric array.
Too often people don't plan ahead for things to grow. I have
run into many commercial programs (mostly on windows) that decide
that my system doesn't have enough memory or disk space, when over
2GB is available. The program stored the value in a 32 bit signed
integer and it was negative. (Running a large program or creating
a large file, such that <2GB is available fixes the problem.)
-- glen
| |
|
| If it were me I would read the line of text into a string (assuming I knew
it would fit), then put the string through a numeric tokenizer. Someone
posted a tokenizer link here not too long ago, I think it was in Arjen
Markus' flibs library?
With a tokenizer you have a lot more control of the process, usually at the
expense of software bloat. However, if reading text files is something you
anticipate doing a lot of, tokenizing is probably worth the effort. As is
putting a bit of care and attention into making the system robust.
As a user of other poeple's Fortran programs, the biggest problem I have had
over the years is very poorly designed text file reading systems. I'm
re-writing a horrid lump of Fortran at the moment that, amongst many other
irritations, falls over if there aren't 2 blank lines between data sections
(not one blank line, not 3 blank lines). Is this documented or is there any
meaningful error message? - of course not. Did the original programmer know
what she was doing? Of course not, she was an aircraft engineer not a
software engineer - 2 blank lines probably looked nicer when it was printed
out.
Paul Holden
<yair999@gmail.com> wrote in message
news:1169137265.826574.62560@s34g2000cwa.googlegroups.com...
> Hi,
>
> Suppose I have an input record as follows:
>
> 5 1. 2. 3. 4. 5.
>
> Where the first integer is in fact the number of following constants.
>
> Is there a more elegant way to read the constants into an allocatable
> array using list directed sequential read than the following?
>
> real, allocatable :: A(:)
> open (5,file='kuku.txtx')
> read (5,*) num
> allocate (A(num))
> backspace 5
> read (5,*) num,A
> end
>
| |
| Louis Krupp 2007-01-18, 7:06 pm |
| yair999@gmail.com wrote:
> Suppose I have an input record as follows:
>
> 5 1. 2. 3. 4. 5.
>
> Where the first integer is in fact the number of following constants.
>
> Is there a more elegant way to read the constants into an allocatable
> array using list directed sequential read than the following?
>
> real, allocatable :: A(:)
> open (5,file='kuku.txtx')
> read (5,*) num
> allocate (A(num))
> backspace 5
> read (5,*) num,A
> end
You *might* be able to get something like this to work:
read(20, advance='no', fmt='(i)') num
allocate (A(num))
read(20, *) A
Or not...
Louis
| |
| Richard Maine 2007-01-18, 7:06 pm |
| On Thu, 18 Jan 2007 14:47:36 -0800, Louis Krupp wrote
(in article <12qvu891gfn82cb@corp.supernews.com> ):
> You *might* be able to get something like this to work:
>
> read(20, advance='no', fmt='(i)') num
....
Yes, I saw the emphasis on the "might" part. To elaborate on it, the use of a
plain "i" (without a field width) is nonstandard. Some compilers accept it.
It being a nonstandard feature that I don't use, I'm not sure whether or not
it would work as desired in this context, but it is plausible. Do be aware of
the nonstandard nature if you choose to use it. I've sure helped an awful lot
of people with porting code that violated the standard, the writer having
cited as rationale that "it wouldn't matter, as it would only ever be used
with one compiler."
--
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
| |
| yair999@gmail.com 2007-01-19, 4:10 am |
|
Richard Maine wrote:
> Yes, I saw the emphasis on the "might" part. To elaborate on it, the use of a
> plain "i" (without a field width) is nonstandard. Some compilers accept it.
Well, my Intel Visual Fortran 9.1 accepted it during compilation, but
running it yielded:
forrtl: severe (64): input conversion error, unit 20, file C:\kuku.txt
| |
| Louis Krupp 2007-01-19, 8:05 am |
| yair999@gmail.com wrote:
> Richard Maine wrote:
>
>
> Well, my Intel Visual Fortran 9.1 accepted it during compilation, but
> running it yielded:
>
> forrtl: severe (64): input conversion error, unit 20, file C:\kuku.txt
>
OK. You might be able to do this:
Initialize n (the element count) to 0.
Read a character without advancing. If the character is a decimal
digit, multiply n by 10, add the numeric value of the digit you just
read, and do this again.
If the character is a space, allocate an array of size n, read it free
form, and you're done, unless you have bad input data somewhere.
If the character is not a space, you have bad input data right here.
But you wanted elegance...
You might be able to hide the alpha to binary conversion in a function
to which you could pass the logical unit number of your input file:
n = read_int_with_no_space(20) [I don't know if underscores are OK]
allocate(A(n))
read(20, *) A
To my knowledge, converting a decimal digit character ('0' through '9')
to its numeric value (0 through 9) is relatively simple:
ichar(c) - ichar('0')
This should work with both ASCII and EBCDIC.
Louis
| |
| yair999@gmail.com 2007-01-19, 7:05 pm |
|
Louis Krupp wrote:
> yair999@gmail.com wrote:
> OK. You might be able to do this:
>
> Initialize n (the element count) to 0.
>
> Read a character without advancing. If the character is a decimal
> digit, multiply n by 10, add the numeric value of the digit you just
> read, and do this again.
>
> If the character is a space, allocate an array of size n, read it free
> form, and you're done, unless you have bad input data somewhere.
>
> If the character is not a space, you have bad input data right here.
>
> But you wanted elegance...
>
> You might be able to hide the alpha to binary conversion in a function
> to which you could pass the logical unit number of your input file:
>
> n = read_int_with_no_space(20) [I don't know if underscores are OK]
> allocate(A(n))
> read(20, *) A
>
> To my knowledge, converting a decimal digit character ('0' through '9')
> to its numeric value (0 through 9) is relatively simple:
>
> ichar(c) - ichar('0')
>
> This should work with both ASCII and EBCDIC.
Well, the following implementation works. Thank you.
integer read_integer
real, allocatable :: A(:)
open (20,file='C:\kuku.txt')
num = read_integer(20)
allocate (A(num))
read (20,*) A
end
integer function read_integer(lun)
character digit
ind = 0
read_integer = 0
do
read (lun,'(A1)',advance='NO') digit
if (digit == ' ' .and. ind == 0) cycle
if (digit == ' ' .and. ind == 1) exit
if (ichar(digit) < ichar('0') .or. ichar(digit) > ichar('9')) stop
'non digit read!'
if (ind == 0) ind = 1
read_integer = 10*read_integer + (ichar(digit) - ichar('0'))
end do
end
| |
| Richard Maine 2007-01-19, 7:05 pm |
| Louis Krupp <lkrupp@pssw.nospam.com.invalid> wrote:
> n = read_int_with_no_space(20) [I don't know if underscores are OK]
Yes, the underscores are ok. They were a nonstandard feature in some f77
compilers (including most of the more recent ones). They were
standardized in f90.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Michael Prager 2007-01-19, 7:05 pm |
| Richard Maine <nospam@see.signature> wrote:
> Sort of related - I didn't mention it at the time, but I second Beliavsky's
> advice to avoid opening units 5 and 6 (or any unit numbers less than 10, but
> 5 and 6 are the "worst"). Those are exactly the unit numbers *MOST* likely to
> have problems. They are often special-cased in several ways.
Would it be unthinkable for the next Fortran standard to make
obsolescent the use of unit numbers < 10 for disk I/O? This
issue comes up again and again and again, and since it's not in
the standard, new users seem to learn about it only by being
burnt.
--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.
| |
| glen herrmannsfeldt 2007-01-19, 7:05 pm |
| Louis Krupp <lkrupp@pssw.nospam.com.invalid> wrote:
> Initialize n (the element count) to 0.
> Read a character without advancing. If the character is a decimal
> digit, multiply n by 10, add the numeric value of the digit you just
> read, and do this again.
(snip)
> But you wanted elegance...
As there is no standard for elegance, it is all subjective.
I would say that BACKSPACE is not elegant, but others would disagree.
(I also find ungetc() not so elegant in C, but it doesn't bother me
that C library routines might use it.)
Assuming a relatively small maximum length, to me reading into
a CHARACTER variable, and reading into a temporary numeric variable
have similar elegance.
It gets more complicated when the possible length is larger.
-- glen
| |
| glen herrmannsfeldt 2007-01-19, 7:05 pm |
| Michael Prager <Mike.Prager.indigo@noaa.gov> wrote:
> Richard Maine <nospam@see.signature> wrote:
He had a /= in his comment, I believe meaning not 5 and 6.
[color=darkred]
> Would it be unthinkable for the next Fortran standard to make
> obsolescent the use of unit numbers < 10 for disk I/O? This
> issue comes up again and again and again, and since it's not in
> the standard, new users seem to learn about it only by being
> burnt.
As far as I know, there is nothing in the standard regarding
preferences for unit numbers. The use of 5 and 6 for stdin and
stdout, or more traditionally card reader and line printer,
is convention but not standard.
I believe that the lower numbers, 1 and 2 for example, were
commonly used for disk I/O in the Fortran 66 days.
I would agree that 5, 6, and 7 (which used to be a card punch)
should not be used for disk I/O.
One system that I used to use used 4 and 5, the mnemonic being
that READ and four letters and WRITE had five. (The first system
that I actually ran Fortran programs on, an NCR Century 100.)
Confusing to everyone else used to 5 and 6.
-- glen
| |
| Richard Maine 2007-01-19, 7:05 pm |
| Michael Prager <Mike.Prager.indigo@noaa.gov> wrote:
> Richard Maine <nospam@see.signature> wrote:
>
(Oh. I missed the "/" part of the "/=", as Glen noted).
[color=darkred]
> Would it be unthinkable for the next Fortran standard to make
> obsolescent the use of unit numbers < 10 for disk I/O? This
> issue comes up again and again and again, and since it's not in
> the standard, new users seem to learn about it only by being
> burnt.
I have pushed much more for the whole concept of unit numbers to be
phased out. I think it is one of Fortran's unfortunate hostorical
features, which made sense in days long ago, but is just a hindrance
today. Patching up little bits of it here and there won't fix it.
I've seen two proposals that I like.
1. The more drastic one, but I think the best in the long run. Introduce
a new non-numeric file "handle". Allow open to return it, and allow it
to be specified in the other I/O statements. Basically, you'd have the
option of using either unit numbers or file handles. That should provide
a transitional capability. Basically the way that most more recent
languages do such things.
2. The best "hack" I've seen is to have a system function to provide an
unused unit number. In order to avoid conflicts with hard-wired unit
numbers in other code, it would have to be a negative number. We already
(in f2003) have the concept of negative unit numbers as something that
the system can assign, but that user's can't otherwise use.
Note that this pretty much has to be a compiler function in order to
avoid all possible conflicts. All attempts to write user-level code to
get unused unit numbers have problems. I have such user-level code
today, as do many people. It's as good as you can do. But it is not and
can not be perfect in terms of interaction with other code. That's
because even if you verify that a unit number is currently unused, that
doesn't guarantee that some other code is going to try to use it later.
The only way to guarantee against such things is to use something that
would not be allowed for other code to use - either a negative number
(which only the compiler is allowed to assign), or something
non-numeric. I prefer the non-numeric approach as making more sense
(units once were numbered things, but aren't any more), but the negative
number will work as a hack and is less drastic a change.
I don't think that obsoleting the use of unit numbers <10 would have
enough impact to be worth doing. The people who pay attention to such
things probaby already have moved beyond hard-wired unit numbers. It
isn't compile-time detectable in general. Compilers are allowed to have
warning messages if they do detect it today. I'd rather go for something
a bit bigger to provide positive help towards fixing the larger problem
of unit number conflicts in general.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| James Giles 2007-01-19, 7:05 pm |
| Richard Maine wrote:
> Michael Prager <Mike.Prager.indigo@noaa.gov> wrote:
....
>
> I have pushed much more for the whole concept of unit numbers to be
> phased out. I think it is one of Fortran's unfortunate hostorical
> features, which made sense in days long ago, but is just a hindrance
> today. Patching up little bits of it here and there won't fix it.
Well, the obsolescent features list is non-normative. And I have it on
the authority of many members and former members of the committee
(including Rich Maine) that they don't think any feature will actually
ever again be removed. Even if the features *are* removed, the majority
of implementations will certainly continue to support them (given
that, for Fortran, the majority of code is "legacy code"). So the idea
of getting a feature "phased out" is awfully optimistic (at least) in that
is presumes that there will be a day when code using the new feature is
significantly more common than legacy code.
Given that, and the fact that Fortran has somehow limped along for 50
years already, I don't see the justification for much additional complexity
in this regard.
> 1. The more drastic one, but I think the best in the long run.
> Introduce a new non-numeric file "handle". Allow open to return it,
> and allow it to be specified in the other I/O statements. Basically,
> you'd have the option of using either unit numbers or file handles.
> That should provide a transitional capability. Basically the way that
> most more recent languages do such things.
This *is* drastic. It adds a new intrinsic data type. It adds a new
control list I/O specifier to all I/O statements (inconsistent with
a previous one). And it *requires* the relevant object to be passed
around to the rest of your program explicitly (to be consistent with
this idea you should have to explicitly pass the handles for the
STDIN/STDOUT files as well).
I mention this last issue because a number of people believe that
the ability to choose a program-wide convention within their programs
for what unit numbers correspond to what files is a significant advantage
of Fortran. Some (Rich Maine, for example) don't care for that advantage.
But that's just a difference of opinion.
> 2. The best "hack" I've seen is to have a system function to provide
> an unused unit number. In order to avoid conflicts with hard-wired
> unit numbers in other code, it would have to be a negative number. We
> already (in f2003) have the concept of negative unit numbers as
> something that the system can assign, but that user's can't otherwise
> use.
I like this idea better. It requires only one change to the language
and can be enforced by the I/O library (that is, you can't really
"accidentally" trip over the new units). The change could be as
simple as one new I/O control list specifier (and only in the
OPEN statement). Instead of saying UNIT=expr, you would
say NEWUNIT=definable_scalar_int. Subsequent I/O statements
refering to the unit would still just use the normal syntax (including
subsequent OPENs of the same unit, which are permitted in order
to change various characteristics of the I/O connection of an already
open file).
Of course, these new unit numbers would have to be passed around
explicitly - I can't offhand think any way for a program to guess what
the appropriate number might be. As I already discussed, those that
don't like this inconvenience wouldn't use the NEWUNIT feature.
--
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
| |
| Gary Scott 2007-01-20, 7:05 pm |
| Richard Maine wrote:
> Michael Prager <Mike.Prager.indigo@noaa.gov> wrote:
>
>
>
>
> (Oh. I missed the "/" part of the "/=", as Glen noted).
>
>
>
>
> I have pushed much more for the whole concept of unit numbers to be
> phased out. I think it is one of Fortran's unfortunate hostorical
> features, which made sense in days long ago, but is just a hindrance
> today. Patching up little bits of it here and there won't fix it.
>
> I've seen two proposals that I like.
>
> 1. The more drastic one, but I think the best in the long run. Introduce
> a new non-numeric file "handle". Allow open to return it, and allow it
> to be specified in the other I/O statements. Basically, you'd have the
> option of using either unit numbers or file handles. That should provide
> a transitional capability. Basically the way that most more recent
> languages do such things.
I still don't quite understand the objection to a numeric "handle" as
presently exists. Numeric handles are almost ubiquitous in modern day
software (e.g. Windows API). You can always associate this numeric
handle with a well-named variable and pass that around. It would be
nice to have an API that can access some of the internal information
stored by the run time or OS and to be able to coordinate IO across DLLS
and separate processes (on the same machine at least). I definitely
don't want to pass a full file path around everywhere and much prefer an
LFN to that. I can't see another scheme helping me in any significant
way.
>
> 2. The best "hack" I've seen is to have a system function to provide an
> unused unit number. In order to avoid conflicts with hard-wired unit
> numbers in other code, it would have to be a negative number. We already
> (in f2003) have the concept of negative unit numbers as something that
> the system can assign, but that user's can't otherwise use.
>
> Note that this pretty much has to be a compiler function in order to
> avoid all possible conflicts. All attempts to write user-level code to
> get unused unit numbers have problems. I have such user-level code
> today, as do many people. It's as good as you can do. But it is not and
> can not be perfect in terms of interaction with other code. That's
> because even if you verify that a unit number is currently unused, that
> doesn't guarantee that some other code is going to try to use it later.
> The only way to guarantee against such things is to use something that
> would not be allowed for other code to use - either a negative number
> (which only the compiler is allowed to assign), or something
> non-numeric. I prefer the non-numeric approach as making more sense
> (units once were numbered things, but aren't any more), but the negative
> number will work as a hack and is less drastic a change.
>
> I don't think that obsoleting the use of unit numbers <10 would have
> enough impact to be worth doing. The people who pay attention to such
> things probaby already have moved beyond hard-wired unit numbers. It
> isn't compile-time detectable in general. Compilers are allowed to have
> warning messages if they do detect it today. I'd rather go for something
> a bit bigger to provide positive help towards fixing the larger problem
> of unit number conflicts in general.
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
***** 5 Jan: Back from 7 days in Cozumel! *****
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Dan Nagle 2007-01-20, 7:05 pm |
| Hello,
Richard Maine wrote:
<snip>
> 1. The more drastic one, but I think the best in the long run. Introduce
> a new non-numeric file "handle". Allow open to return it, and allow it
> to be specified in the other I/O statements. Basically, you'd have the
> option of using either unit numbers or file handles. That should provide
> a transitional capability. Basically the way that most more recent
> languages do such things.
This idea may be best in the long haul, but it requires
the most work for its definition.
For example, should the new type be a "unit type" or a "file type" ?
<snip>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Walter Spector 2007-01-20, 7:05 pm |
| Dan Nagle wrote:
> ...
> For example, should the new type be a "unit type" or a "file type" ?
A simple default integer would suffice. Have OPEN return a unit number
(if it needs to be a negative value, so be it), and then a code can use
that unit number in other I/O statements in the usual way.
W.
| |
| Richard Maine 2007-01-20, 7:05 pm |
| Gary Scott <garylscott@sbcglobal.net> wrote:
> I still don't quite understand the objection to a numeric "handle" as
> presently exists. Numeric handles are almost ubiquitous in modern day
> software (e.g. Windows API). You can always associate this numeric
> handle with a well-named variable and pass that around. It would be
> nice to have an API that can access some of the internal information
> stored by the run time or OS and to be able to coordinate IO across DLLS
> and separate processes (on the same machine at least). I definitely
> don't want to pass a full file path around everywhere and much prefer an
> LFN to that. I can't see another scheme helping me in any significant
> way.
Windows uses numeric handles? Yukk. Didn't know that. I don't like lots
of things about it; guess that's one more. I don't know much about the
WIndows API (obviously), but I would in general say the opposite - that
numeric handles are relatively rare overall. In fact, I would have said
that the term "handle" in this context usualy indicates something that
you can't "see" inside of or manipulate directly. Are you sure that
these WIndows handles are documented as user-visible numers, or are you
just talking about the internal implementation? Yes, it makes a big
difference whether it is documented and user visible versus being
internal implementation - because that distinction is the whole point.
Anyway, regardless of what one thinks is "common", the objections are
1. The scheme of having the user define the numeric values has numerous
problems. I hope you understand that, because its problems are
"obvious". It coudl be ok for small programs written by a single person
or cohesive group. But when you use code (such as libraries) from many
sources, the problem becomes something that must be worked around. For
every piece of code in a program, you need to know what unit numbers it
uses. Yes, one can develop an assignment scheme, but that only works if
all the code uses the same scheme. That counts as a workaround for a
problem. I have seen cases where I wanted to use 2 3rd party libraries,
each of which used the same unit number. The particular unit number was
hard-wired into the code of thee 3rd party library, which was not
accessible to us. This kind of thing is even more fun when the usage
isn't documenteed.
2. For system-defined numbers, the numeric nature provides no benefit,
but has problems. Anything you do that uses the numeric properties is
pretty much guaranteed to be an error. Thus, making them numeric
provides opportunity for accidental errors. For heavens sake, look at
all the times that matters come up about what numbers are advisabel to
use or not. That all comes from theirt being numeric.
Egads, no, one wouldn't use the path name! That's worse than a unit
number; has even more problems. I suspect you don't understand the
concept of an abstract handle if you think that's the kind of thing
advocated.
No, a handle would be something of a separate data type, all of its own.
Typically it would be a like a derived type with private components. In
fact, that's exactly what user-defined handles for various things are
are today. (I have *LOTS* of them for my stuff). By design, you have no
idea what is "inside" of it, because you don't care. It is just a
"handle" by which you can manipulate the file. The internal
implementation is reasonably to be something like a pointer to the
internal place where the information about the file is stored, or
possibly even a numeric index into an array of such areas. But a
significant pooint is that you don't know what the exact internal
structure is, because it doesn't directly matter to you as a user.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Richard Maine 2007-01-20, 7:05 pm |
| Dan Nagle <dannagle@verizon.net> wrote:
> Richard Maine wrote:
>
> This idea may be best in the long haul, but it requires
> the most work for its definition.
>
> For example, should the new type be a "unit type" or a "file type" ?
Are you asking about the name for it or the functionality? The name
would need to be decided. I wouldn't have thought that the functionality
would even be in question. Or maybe I don't understand the question. It
is a replacement for a unit number - not a file. It would therefore play
the same role as a unit number in all places. The only difference would
be that it was a different type (so the user can't manipulate its
values) and that the OPEN would constitute a variable definition context
for it. In fact, there would probably be intrinsic functions (or perhaps
subroutines, to allow for error handling) to give a handle from a unit
number or vise versa, so as to facilitate transition in large programs.
For details, see the paper Malcolm wrote not too many years ago. He had
everything laid out in full detail as I recall. I was dissapointed that
the paper didn't pass.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Ron Shepard 2007-01-20, 7:05 pm |
| In article <1hs8gti.8x12mqp78mbbN%nospam@see.signature>,
nospam@see.signature (Richard Maine) wrote:
> No, a handle would be something of a separate data type, all of its own.
> Typically it would be a like a derived type with private components.
This terminology is a little confusing. Often, a "handle" is an
integer that points to such a structure and not the structure
itself. Such indirection is used when the language does not support
the structure directly (e.g. the posix f77 interface), or when the
structure itself often needs to be reorganized or moved around in
memory (the handle address remains the same, but it points to
different locations when necessary).
Indeed, fortran unit numbers are one example of such a "handle",
although as you point out, it is bad programming style for
independent program units to make assumptions about unit number
values. It is really that bad programming style that is the
problem, not the idea of integer handles themselves. Your idea of
changing from a simple integer to a private structure is one way to
discourage that bad programming style.
$.02 -Ron Shepard
| |
| Gary Scott 2007-01-20, 7:05 pm |
| Richard Maine wrote:
> Gary Scott <garylscott@sbcglobal.net> wrote:
>
>
>
>
> Windows uses numeric handles? Yukk. Didn't know that. I don't like lots
> of things about it; guess that's one more. I don't know much about the
> WIndows API (obviously), but I would in general say the opposite - that
> numeric handles are relatively rare overall. In fact, I would have said
> that the term "handle" in this context usualy indicates something that
> you can't "see" inside of or manipulate directly. Are you sure that
> these WIndows handles are documented as user-visible numers, or are you
> just talking about the internal implementation? Yes, it makes a big
> difference whether it is documented and user visible versus being
> internal implementation - because that distinction is the whole point.
> Anyway, regardless of what one thinks is "common", the objections are
>
> 1. The scheme of having the user define the numeric values has numerous
> problems. I hope you understand that, because its problems are
> "obvious". It coudl be ok for small programs written by a single person
> or cohesive group. But when you use code (such as libraries) from many
> sources, the problem becomes something that must be worked around. For
> every piece of code in a program, you need to know what unit numbers it
> uses. Yes, one can develop an assignment scheme, but that only works if
> all the code uses the same scheme. That counts as a workaround for a
> problem. I have seen cases where I wanted to use 2 3rd party libraries,
> each of which used the same unit number. The particular unit number was
> hard-wired into the code of thee 3rd party library, which was not
> accessible to us. This kind of thing is even more fun when the usage
> isn't documenteed.
>
> 2. For system-defined numbers, the numeric nature provides no benefit,
> but has problems. Anything you do that uses the numeric properties is
> pretty much guaranteed to be an error. Thus, making them numeric
> provides opportunity for accidental errors. For heavens sake, look at
> all the times that matters come up about what numbers are advisabel to
> use or not. That all comes from theirt being numeric.
>
> Egads, no, one wouldn't use the path name! That's worse than a unit
> number; has even more problems. I suspect you don't understand the
> concept of an abstract handle if you think that's the kind of thing
> advocated.
That may be because every handle I've been exposed to (windows API) is
simply an integer ID, similar to an LFN. It is an absolute system wide
identifier for a process, window, thread, GUI widget, etc that has to be
passed around (in the Windows API context it is certainly a huge PITA,
but it is what it is). However, there are facilities to query what that
handle is in certain cases, but the common method is to pass it around
directly. So, with facilities to query what LFN/handle is associated
with what (I'd like certain other attributes queriable also such as
access rights, security settings), it seems resolvable to me within the
context of a numeric LFN/handle as currently exists. I would agree that
using negative LFN numbers would probably be required going forward,
with conflicts already built into existing applications. I don't oppose
necessarily hiding the LFN value behind an API. Most libraries I've
been exposed to do not hard code Fortran LFN numbers, they let you pick
one or they use a C API internally so that it doesn't matter. I'd just
call that bad API design for a 3rd party API designed for use by others.
>
> No, a handle would be something of a separate data type, all of its own.
> Typically it would be a like a derived type with private components. In
> fact, that's exactly what user-defined handles for various things are
> are today. (I have *LOTS* of them for my stuff). By design, you have no
> idea what is "inside" of it, because you don't care. It is just a
> "handle" by which you can manipulate the file. The internal
> implementation is reasonably to be something like a pointer to the
> internal place where the information about the file is stored, or
> possibly even a numeric index into an array of such areas. But a
> significant pooint is that you don't know what the exact internal
> structure is, because it doesn't directly matter to you as a user.
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
***** 5 Jan: Back from 7 days in Cozumel! *****
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Gary Scott 2007-01-20, 7:05 pm |
| Ron Shepard wrote:
> In article <1hs8gti.8x12mqp78mbbN%nospam@see.signature>,
> nospam@see.signature (Richard Maine) wrote:
>
>
>
>
> This terminology is a little confusing. Often, a "handle" is an
> integer that points to such a structure and not the structure
> itself. Such indirection is used when the language does not support
> the structure directly (e.g. the posix f77 interface), or when the
> structure itself often needs to be reorganized or moved around in
> memory (the handle address remains the same, but it points to
> different locations when necessary).
>
> Indeed, fortran unit numbers are one example of such a "handle",
> although as you point out, it is bad programming style for
> independent program units to make assumptions about unit number
> values. It is really that bad programming style that is the
> problem, not the idea of integer handles themselves. Your idea of
> changing from a simple integer to a private structure is one way to
> discourage that bad programming style.
It just seems to me to be such a nitnoid problem, easily worked around
with only a tiny amount of discipline. I'd much rather we focus on
threads, processes, a better bit string datatype than being proposed.
>
> $.02 -Ron Shepard
--
Gary Scott
mailto:garylscott@sbcglobal dot net
***** 5 Jan: Back from 7 days in Cozumel! *****
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Richard Maine 2007-01-20, 7:05 pm |
| Ron Shepard <ron-shepard@NOSPAM.comcast.net> wrote:
> In article <1hs8gti.8x12mqp78mbbN%nospam@see.signature>,
> nospam@see.signature (Richard Maine) wrote:
>
>
> This terminology is a little confusing. Often, a "handle" is an
> integer that points to such a structure and not the structure
> itself.
Oh. Definitely. Putting the data it self in the handle would cause lots
of problems to the extent that I'd think it unworkable. After all, you
want to be able to have copies of the handle in all kinds of situations.
For a start, you want to be able to pass them as arguments. You might
want to have an array of them, or store copies of them in user
structures. All kinds of things. To me that's part of being a "handle".
Those private components are likely to consist of just a single integer
or pointer. Might even be the same thing as the current Fortran luns.
The "private" bit is the main distinction I'm making. Because the
component(s) are private, you can't do numeric operations on them
directly.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Richard Maine 2007-01-20, 7:05 pm |
| Gary Scott <garylscott@sbcglobal.net> wrote:
> It just seems to me to be such a nitnoid problem, easily worked around
> with only a tiny amount of discipline.
As I said elsethread, the problem is biggest when code from multiple
sources is involved. I can (and do) discipline myself on this matter.
When you use libraries from multiple sources, you can't control them.
Furthermore, even if each of multiple independent libraries is
internally disciplined, that doesn't mean they will work well together.
Resource allocation (in this case, the resources are the unit numbers,
but general principles of resource allocation applies) is pretty
intractible without either a central allocator (such as the compiler
runtime library) or at least an agreed on convention. It doesn't work
well when done completely independently.
For a nitnoid problem, it sure causes lots of trouble. Have you noted
the number of times that selection of unit numbers comes up on this
newsgroup alone for example? I'd put variants of "what unit numbers
should I use?" or "why was that a bad choice of unit number?" as fairly
high on the Fortran FAQ list. And when "funny" things happen with file
I/O, looking for accidentally conflicting uses of the same unit number
is one of the things I make sure to do in debugging.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Gary Scott 2007-01-20, 7:05 pm |
| Richard Maine wrote:
> Gary Scott <garylscott@sbcglobal.net> wrote:
>
>
>
>
> As I said elsethread, the problem is biggest when code from multiple
> sources is involved. I can (and do) discipline myself on this matter.
> When you use libraries from multiple sources, you can't control them.
> Furthermore, even if each of multiple independent libraries is
> internally disciplined, that doesn't mean they will work well together.
> Resource allocation (in this case, the resources are the unit numbers,
> but general principles of resource allocation applies) is pretty
> intractible without either a central allocator (such as the compiler
> runtime library) or at least an agreed on convention. It doesn't work
> well when done completely independently.
>
> For a nitnoid problem, it sure causes lots of trouble. Have you noted
> the number of times that selection of unit numbers comes up on this
> newsgroup alone for example? I'd put variants of "what unit numbers
> should I use?" or "why was that a bad choice of unit number?" as fairly
> high on the Fortran FAQ list. And when "funny" things happen with file
> I/O, looking for accidentally conflicting uses of the same unit number
> is one of the things I make sure to do in debugging.
>
But we aren't talking about removing the existing methodology, so it
will be another 30 years before any change will impact this problem area
in any significant way. I suspect that the vast majority will continue
using the old method. I'm not opposed at all, I'll just say that it
would be low on my personal priority list.
--
Gary Scott
mailto:garylscott@sbcglobal dot net
***** 5 Jan: Back from 7 days in Cozumel! *****
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| James Giles 2007-01-20, 7:05 pm |
| Richard Maine wrote:
....
> Windows uses numeric handles? Yukk. [...]
I think some unixes use a raw pointer to a file table entry.
Double yukk!!
--
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
| |
| Dan Nagle 2007-01-20, 7:05 pm |
| Hello,
Richard Maine wrote:
> Dan Nagle <dannagle@verizon.net> wrote:
<snip>
>
> Are you asking about the name for it or the functionality? The name
> would need to be decided. I wouldn't have thought that the functionality
> would even be in question. Or maybe I don't understand the question. It
> is a replacement for a unit number - not a file.
Why bother? If you want a new type, should it not hold the open modes
as well as an index into the open file table? Perhaps even a way
to query file position? Allow changing the status for closing?
> It would therefore play
> the same role as a unit number in all places. The only difference would
> be that it was a different type (so the user can't manipulate its
> values) and that the OPEN would constitute a variable definition context
> for it.
Other than being a distinct type so the compiler can enforce
prohibitions on assignment, what's the advantage?
It must be a sequence type, so it can fit into common, so older codes
can be migrated to the new system. Thus, it's still subject
to overwrites etc.
> In fact, there would probably be intrinsic functions (or perhaps
> subroutines, to allow for error handling) to give a handle from a unit
> number or vise versa, so as to facilitate transition in large programs.
Which is exactly why Malcolm's proposal didn't go forward.
No such functions were ever provided in any subsequent paper.
(The requirement for them was made at the Delft meeting with WG5.)
> For details, see the paper Malcolm wrote not too many years ago. He had
> everything laid out in full detail as I recall. I was dissapointed that
> the paper didn't pass.
Unless integer <-> unit_t conversions are included, and I quote Groucho,
"Whatever it is, I'm against it!" :-)
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Richard Maine 2007-01-20, 7:05 pm |
| Dan Nagle <dannagle@verizon.net> wrote:
> Why bother? [with non-numeric unit handles]
I think I've covered why I would want such a thing elsethread.
> If you want a new type, should it not hold the open modes
> as well as an index into the open file table? Perhaps even a way
> to query file position? Allow changing the status for closing?
And this also. As discussed, one would not want the data actually in the
new handle type; one would want the handle to just "point" (via any of
several methos - intener index or address pointer seem likely) to the
record of connection data that already exists.
Those things you listed are all things one would want to be able to do
to a connection. They have zero to do with the concept of a handle type.
The new type would be nothing but a new form of identifier for the
connection. All the existing I/O statements would allow it as an
alternative for the unit number. Not even really any new syntax needed,
as it is trivially compile-time detectable whether you used an integer.
You are asking about functionalities that oen might want for a
connection. That is completely orthogonal to the concept of what form
one uses for an identifier of the connection - so much so that I'm not
at all sure I have correctly communicated the concept to you.
> Other than being a distinct type so the compiler can enforce
> prohibitions on assignment, what's the advantage?
Actually, it is prohibitions on operations - not on assignment. One
would, of course, allow assignment. One would not, however, allow
arithmetic or other operations. With that substitution, which I assume
you meant, you are asking "other than its advantages, what are its
advantages?" :-) See my postings elsethread. No point in repeating them.
If they didn't convince you, then repeating them isn't likely. But you
seem to be asking as though you hadn't read my other postings. Perhaps
you are just using the rhetorical form of a question to say that you
don't agree those are sufficient advantages.
>
> Which is exactly why Malcolm's proposal didn't go forward.
Really? I have trouble believing that as a root cause, because it is too
trivially rectified. If people cited that as the reason, then I think
I'll claim they were covering for some deeper aversion to the concept.
Next, I'll hear that some technical proposal didn't go through becasue
there was a spelling error in the proposal and it was too much trouble
to fix that? Some of the things that are going forward have had changes
hugely larger than that at times later than that. Nah. I might believe
that was cited as the reason, and maybe even that some people believed
that was their reason. But I don't think there is much chance of my
being convinced that actually was the real underlying reason.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| James Giles 2007-01-20, 7:05 pm |
| Dan Nagle wrote:
....
> Why bother? If you want a new type, should it not hold the open modes
> as well as an index into the open file table? Perhaps even a way
> to query file position? Allow changing the status for closing?
Now that's a *much* more interesting idea. Just having handles
is too much complexity (though, as a result of this discussion,
I've thought of a few ways to reduce that complexity). The "problem"
it solves is not sufficiently common nor sufficiently hard to deal
with that the additional feature is really justified. But, having the
new data type provide more succinct and clearer ways of dealing
with files might be interesting enough to justify discussing the
feature (though still probably not enough to adopt it).
Given a new intrinsic type (say IO_HANDLE), you wouldn't need
any new I/O specifiers (unlike I thought before) in the control lists
since such lists can be generic. For example:
OPEN(unit=N, ...)
If N is of type INTEGER, the ususal semantics apply. If N is of
type IO_HANDLE, the new semantics apply. The syntax of the I/O
statements themselves would be unchanged.
But suppose that N was of type IO_HANDLE, then the following
might be reasonable:
N%BLANK = 'null'
current_mode = N%ROUND
Or, suppose N is an IO_HANDLE opened for direct formatted I/O,
you could pass it to a subroutine like:
Subroutine XYZ(N, ...)
type(IO_HANDLE) :: N
character(N%RECL) :: buffer
And this would declare the variable BUFFER to be exactly the right
length for a single record of the file without having to pass that length
as a separate argument. And without needing to use the rather verbose
INQUIRE statement (which can't be used in a declaration anyway - or
I suppose you could write a specifiation function that you could pass
the file handle to, it could do the INQUIRE and return the length....
the point is that INQUIRE is inconvenient here).
What about doing I/O thought the handle? Suppose that N is the
IO_HANDLE for a file opened for unformatted 'stream' I/O. Then
couldn't you get the next word of data from the file with:
Data = N%NEXT
This is an absurd exaggeration of the possibilities. But I always
think: consider everything and keep only the few best ideas.
As I say, this might be enough new capability to justify the new
complexity. I doubt it, but maybe. The real problem is still
that most Fortran is legacy code and is unlikely to ever be
rewritten to use this feature.
--
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
| |
| Dan Nagle 2007-01-22, 8:15 am |
| Hello,
Richard Maine wrote:
> Dan Nagle <dannagle@verizon.net> wrote:
<snip "unit type" v. "file type">
>
> Really? I have trouble believing that as a root cause, because it is too
> trivially rectified. If people cited that as the reason, then I think
> I'll claim they were covering for some deeper aversion to the concept.
The "concept aversion" was between those who favored a completely
new, opaque unit type, with no operations, no assignment etc, just
a name for objects of that type. Completely useless for anyone
dealing with libraries, because you can't convert unit type thingos
to integers, and vv.
The other side wanted a distinct type, but wanted to allow evolution
of older codes via conversion between integers and unit type.
The compromise was to go ahead with a strictly separate unit type,
but only if conversion functions were provided. The proponents
of the unit type never produced a follow-up paper containing
the feature with the conversion intrinsics. Thus, it died.
> Next, I'll hear that some technical proposal didn't go through becasue
> there was a spelling error in the proposal and it was too much trouble
> to fix that? Some of the things that are going forward have had changes
> hugely larger than that at times later than that. Nah. I might believe
> that was cited as the reason, and maybe even that some people believed
> that was their reason. But I don't think there is much chance of my
> being convinced that actually was the real underlying reason.
Possibly it was simply a cost - benefit judgment.
Or just the way the votes were cast.
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Richard Maine 2007-01-22, 8:15 am |
| Richard Maine <nospam@see.signature> wrote:
> Dan Nagle <dannagle@verizon.net> wrote:
>
> you are asking "other than its advantages, what are its
> advantages?" :-) See my postings elsethread.
But now that you prompt me to think further (often a good idea), I
recall one other advantage that I hadn't mentioned before in this
thread. In fact, it is probably closer to the crux of the matter. The
prohibitions against operations are just a side effect of getting the
core "right". Or looking from the other direction, the ability to mess
up by accidentally doing arithmetic is just a side effect of getting the
core "wrong".
The handle shouldn't be numeric because its essential meaning isn't
numeric. This comes up in teaching the language. Having the handle be
non-numeric avoids conversations like the following (and yes, I've had
conversations like that).
"What do I use for the unit number?"
"Doesn't much matter. Just pick a random number."
"But how do I pick? What number should I pick?"
"Any positive number."
"Ok. I'll pick 1."
"No. Not that one."
"Oh. Why not?"
"Small numbers are sometimes problems. Pick something bigger."
"Oh. Ok. I'll pick 123456789."
"Um. No. Not that big. That's not a good idea."
"Oh. Then what should I pick?"
... etc.
Or conversely, on seeing unit number 37 used in an existing code...
"What does the 37 mean?"
"Nothing. Its just a random number."
"Well then why is it 37?"
"Don't worry about it."
"I'm having some problem. Maybe things would work better with
a different number."
"No. That wouldn't make any difference."
"Why not? I'll try just in case."
... etc.
On seeing numeric things, people naturally tend to assume that the
number has some, well, numeric meaning. It doesn't here. There is no
implication that unit 37 is the 37'th of something. In days of yore
there was such an implication, but not now. Avoiding that false
implication and the misunderstandings that arrise from it is one of the
benefits.
And yes, I know that old code won't magically suddenly change. But I
don't buy the argument that we might as well never bother to improve
anything, which is where an extrapolation of that leads.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Richard Maine 2007-01-22, 8:15 am |
| Dan Nagle <dannagle@verizon.net> wrote:
[on why the non-numeric unit handle proposal failed.]
> Possibly it was simply a cost - benefit judgment.
That's certainly possible. I'd have voted the other way, but I'm
familliar with different people having different judgements on such
matters.
> Or just the way the votes were cast.
Touche! I should be familliar enough with that answer. I've given it
enough times myself. :-)
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Dan Nagle 2007-01-22, 8:15 am |
| Hello,
Richard Maine wrote:
> Dan Nagle <dannagle@verizon.net> wrote:
> [on why the non-numeric unit handle proposal failed.]
>
> That's certainly possible. I'd have voted the other way, but I'm
> familliar with different people having different judgements on such
> matters.
I voted against it, somewhat due to the lack of conversions (migrating
old code). But more because we haven't really thought through
the whole idea of intrinsic derived types.
I had to stop a repetitious discussion at a recent meeting
about what a newly proposed intrinsic type would be.
Precedent, or the desirability of the lack thereof, got
out of control.
We spend too much time finding shiny pebbles.
Let's think about what intrinsic derived types mean
before we start littering the beach with them. :-)
<snip>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Richard Maine 2007-01-22, 8:15 am |
| Dan Nagle <dannagle@verizon.net> wrote:
> But more because we haven't really thought through
> the whole idea of intrinsic derived types.
Yes. That's been a bit of a pet peeve of mine for a while - anyway, ever
since Van started me thinking along those lines. I don't think J3 has
effectively used some of the facilities of the language (such as modules
and derived types) in the standard itself. There are several areas
where, if I were doing a comparable thing as a user, I'd use a derived
type, but the standard doesn't, and I think suffers for it. This
particular case, (non-numeric unit numbers) is a replacement for an old
feature, so there are arguments about whether it is worth doing at all
(as some have noted). But there are other features that are completely
new and we did do - but I don't think we did as well as we should have
because of not taking advantage of things like derived types.
I think Van had a good idea on refactoring some of the type stuff, but
yes, it does take a fair amount of thought/work (which I think he
underestimated). In particular, I'm thinking of his idea of separating
type classification into 2 dimensions, instead of the 1 (and a half)
that we currently have. In particular, derived vs intrinsic really cuts
across 2 separate concepts,which I might call.
1. Intrinsic (defined by the standard or processor) vs user-defined.
2. Atomic vs derived (derived has teh sense of being built up or derived
from smaller pieces).
All 4 combinations could concievably exist (though atomic user-defined
is a bit odd). Right now, we tend to identify all intrinsic types as
being atomic, and all user-defined types as being derived. There are a
few intrinsic derived types, but, yes, we haven't done a very good job
of laying a solid groundwork for them, I agree.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| glen herrmannsfeldt 2007-01-22, 8:15 am |
| Dan Nagle wrote:
(snip about replacements for UNIT numbers in I/O statements)
> I had to stop a repetitious discussion at a recent meeting
> about what a newly proposed intrinsic type would be.
> Precedent, or the desirability of the lack thereof, got
> out of control.
I hadn't thought of it that way before.
C has the FILE type, though normally a FILE* pointer is used.
It is not intrinsic in the way you mean. It is declared in stdio.h
just like any user defined type. FILE is usually a typedef
to a struct, but I believe even that is implementation dependent.
Typedef allows one to give a name to a type, either a new name for
a standard type, or for a struct, union, or enum, that can be used
in the same way as any other type name. In Fortran terms, a struct
typedef would be similar to a defined type without the need to say
TYPE everywhere. The value of a FILE* variable can be passed to
other functions in the usual ways.
----------------------------------------------------------
In PL/I, the equivalent of unit numbers are FILE constants. They are
declared similar to variables, but are constants in the same way that
Fortran unit number are. They can be INTERNAL (local) or EXTERNAL
(global), with the latter being the default. (The name is not
necessarily related to the file name, though might be the default
if no other name is specified.) One can, for example,
OPEN FILE(XYZ) OUTPUT STREAM SEQUENTIAL UNBUFFERED TITLE('THIS.OUT');
In another procedure
PUT FILE(XYZ) LIST(X,Y,Z);
FILE variables can be used in the same way that INTEGER variables are
used for unit numbers in Fortran, to pass FILE constants around.
-- glen
| |
| Dan Nagle 2007-01-22, 8:15 am |
| Hello,
Richard Maine wrote:
> Dan Nagle <dannagle@verizon.net> wrote:
>
>
> Yes. That's been a bit of a pet peeve of mine for a while - anyway, ever
> since Van started me thinking along those lines. I don't think J3 has
> effectively used some of the facilities of the language (such as modules
> and derived types) in the standard itself. There are several areas
> where, if I were doing a comparable thing as a user, I'd use a derived
> type, but the standard doesn't, and I think suffers for it. This
> particular case, (non-numeric unit numbers) is a replacement for an old
> feature, so there are arguments about whether it is worth doing at all
> (as some have noted).
One advantage of a file type over a unit type is that I could extend
the file type to add stuff peculiar to my application. Then I'd have
"everything in one place" for control of files.
But when we make intrinsic derived types, do we make them as wide
as we can, or as specific as we can. We've given ourselves no guidance.
<snip>
> 1. Intrinsic (defined by the standard or processor) vs user-defined.
>
> 2. Atomic vs derived (derived has teh sense of being built up or derived
> from smaller pieces).
>
> All 4 combinations could concievably exist (though atomic user-defined
> is a bit odd). Right now, we tend to identify all intrinsic types as
> being atomic, and all user-defined types as being derived. There are a
> few intrinsic derived types, but, yes, we haven't done a very good job
> of laying a solid groundwork for them, I agree.
But first, you must define atomic. :-)
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Gary Scott 2007-01-22, 8:15 am |
| glen herrmannsfeldt wrote:
> Dan Nagle wrote:
>
> (snip about replacements for UNIT numbers in I/O statements)
>
>
>
> I hadn't thought of it that way before.
>
> C has the FILE type, though normally a FILE* pointer is used.
>
> It is not intrinsic in the way you mean. It is declared in stdio.h
> just like any user defined type. FILE is usually a typedef
> to a struct, but I believe even that is implementation dependent.
>
> Typedef allows one to give a name to a type, either a new name for
> a standard type, or for a struct, union, or enum, that can be used
> in the same way as any other type name. In Fortran terms, a struct
> typedef would be similar to a defined type without the need to say
> TYPE everywhere. The value of a FILE* variable can be passed to
> other functions in the usual ways.
I despise the proliferation of types with identical internal
representation that this typically generates in C code. It may be
object oriented, but it drastically complicates analysis and especially
interlanguage operability (not that a typical C programmer cares about that)
>
> ----------------------------------------------------------
>
> In PL/I, the equivalent of unit numbers are FILE constants. They are
> declared similar to variables, but are constants in the same way that
> Fortran unit number are. They can be INTERNAL (local) or EXTERNAL
> (global), with the latter being the default. (The name is not
> necessarily related to the file name, though might be the default
> if no other name is specified.) One can, for example,
>
> OPEN FILE(XYZ) OUTPUT STREAM SEQUENTIAL UNBUFFERED TITLE('THIS.OUT');
>
> In another procedure
>
> PUT FILE(XYZ) LIST(X,Y,Z);
>
> FILE variables can be used in the same way that INTEGER variables are
> used for unit numbers in Fortran, to pass FILE constants around.
>
> -- glen
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
***** 5 Jan: Back from 7 days in Cozumel! *****
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Pierre Asselin 2007-01-22, 8:15 am |
| Richard Maine <nospam@see.signature> wrote:
> The handle shouldn't be numeric because its essential meaning isn't
> numeric. This comes up in teaching the language. Having the handle be
> non-numeric avoids conversations like the following (and yes, I've had
> conversations like that).
> "What do I use for the unit number?"
> "Doesn't much matter. Just pick a random number."
> "But how do I pick? What number should I pick?"
> "Any positive number."
> "Ok. I'll pick 1."
> "No. Not that one."
> "Oh. Why not?"
> "Small numbers are sometimes problems. Pick something bigger."
> "Oh. Ok. I'll pick 123456789."
> "Um. No. Not that big. That's not a good idea."
> "Oh. Then what should I pick?"
> ... etc.
The problem here is not that the handle is numeric, but that the
the responsibility for its value is forced on the user. In
retrospect, that was a bad idea. It causes no end of trouble when
integrating codes from different authors. To make matters worse,
there are no guidelines for choosing a value, as Richard reminds
us above.
I think we can profit from experience in other languages. Richard's
opaque handle resembles a FILE * from the C stdio library, but
let's not forget that under stdio is a low-level file handle provided
by the operating system. Under Posix, this handle is an integer;
a quick check on MSDN [1] reveals a similar interface under Windows,
also with integer handles. I agree in principle with Richard's
aversion to integer handles, but *it is not a problem in practice*.
The temptation to use arithmetic on handle variables or to otherwise
clobber them must not be that strong, because users just don't do
that. The big difference with Fortran is that the numerical value
is chosen by the open() call instead of the user.
The minimal change to Fortran could be a new key in the OPEN
statement, for example OPEN(NEWUNIT=ivar, FILE=...). The old
OPEN(unit=ival, FILE=...) and plain OPEN(ival, FILE=...) must
continue to work as before so old code doesn't need to be changed,
but new code can be written to the new feature. I don't care much
about the spelling. I haven't worked out the consequences to the
rest of the language, but surely a change confined to the parentheses
of the OPEN statement can be circumscribed.
If the processor-chosen unit is made negative to avoid conflicts
when mixing old and new styles, I would request an integer parameter
in some standard module to designate an impossible unit. (Posix
doesn't need such because the handle has always been "a small,
non-negative integer".)
[1] http://msdn.microsoft.com/library/d...evel_i.2f.o.asp
--
pa at panix dot com
| |
| Gary Scott 2007-01-22, 8:15 am |
| Pierre Asselin wrote:
> Richard Maine <nospam@see.signature> wrote:
>
>
>
>
>
>
> The problem here is not that the handle is numeric, but that the
> the responsibility for its value is forced on the user. In
> retrospect, that was a bad idea. It causes no end of trouble when
> integrating codes from different authors. To make matters worse,
> there are no guidelines for choosing a value, as Richard reminds
> us above.
>
> I think we can profit from experience in other languages. Richard's
> opaque handle resembles a FILE * from the C stdio library, but
> let's not forget that under stdio is a low-level file handle provided
> by the operating system. Under Posix, this handle is an integer;
> a quick check on MSDN [1] reveals a similar interface under Windows,
> also with integer handles. I agree in principle with Richard's
> aversion to integer handles, but *it is not a problem in practice*.
> The temptation to use arithmetic on handle variables or to otherwise
> clobber them must not be that strong, because users just don't do
> that. The big difference with Fortran is that the numerical value
> is chosen by the open() call instead of the user.
>
> The minimal change to Fortran could be a new key in the OPEN
> statement, for example OPEN(NEWUNIT=ivar, FILE=...). The old
> OPEN(unit=ival, FILE=...) and plain OPEN(ival, FILE=...) must
> continue to work as before so old code doesn't need to be changed,
> but new code can be written to the new feature. I don't care much
> about the spelling. I haven't worked out the consequences to the
> rest of the language, but surely a change confined to the parentheses
> of the OPEN statement can be circumscribed.
I personally don't consider that to be any better than an
INQUIRE(FREEUNIT=ivar) method followed by a normal OPEN(UNIT...). I
consider INQUIRE to be more natural, otherwise, you're having OPEN
perform an implicit inquire with the NEWUNIT specifier. It also allows
you to INQUIRE a free unit without immediately opening/assigning to
something.
>
> If the processor-chosen unit is made negative to avoid conflicts
> when mixing old and new styles, I would request an integer parameter
> in some standard module to designate an impossible unit. (Posix
> doesn't need such because the handle has always been "a small,
> non-negative integer".)
>
>
> [1] http://msdn.microsoft.com/library/d...evel_i.2f.o.asp
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
***** 5 Jan: Back from 7 days in Cozumel! *****
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| glen herrmannsfeldt 2007-01-22, 8:15 am |
| Gary Scott wrote:
(snip regarding C's typedef)
> I despise the proliferation of types with identical internal
> representation that this typically generates in C code. It may be
> object oriented, but it drastically complicates analysis and especially
> interlanguage operability (not that a typical C programmer cares about
> that)
Well, yes. Though when you have to write code that is dependent
on specific width types, it is convenient to have types like INT32,
which will typedef (or #define) the appropriate type on the target
machine.
Also, I don't find the word struct so bad that I go through the extra
effort of using typedef to remove it. It is convenient in the case at
hand, what would be an intrinsic defined type, but is in fact just
a typedef.
-- glen
| |
| Richard Maine 2007-01-22, 8:15 am |
| Gary Scott <garylscott@sbcglobal.net> wrote:
> Pierre Asselin wrote:
Yes. Thats the other possibility that I alluded to (quite a bit) earlier
in the thread. I haven't kept careful track, but I believe something
along that lines went forward. It is a lot less impact than teh new data
type idea.
[color=darkred]
> I personally don't consider that to be any better than an
> INQUIRE(FREEUNIT=ivar) method followed by a normal OPEN(UNIT...). I
> consider INQUIRE to be more natural, otherwise, you're having OPEN
> perform an implicit inquire with the NEWUNIT specifier. It also allows
> you to INQUIRE a free unit without immediately opening/assigning to
> something.
I personally consider it quite natural for the OPEN to assign it. The
OPEN is what creates the connection, and it gives you an identifier
(even if an integer one) for it. That's much like what most other
languages do.
It also avoids all possibility of conflicts with user-assigned units in
existing codes. With inquire, you are presumably talking about assigning
a "normal" (i.e. positive) unit number. This can conflict with
user-selected ones. Finding out what unit numbers are free right now
doesn't cut it. That we can (and do) already have. I've got a
user-written procedure to do that, as do many other people. But that
gives you no guarantee against conflict with some later OPEN that is
hardwired to use the same unit number. It is better than nothing, but
that is a significant hole. Having OPEN return a negative unit number,
which can't conflict with an open of a valid user-assigned unit number,
avoids that problem. Inquire can't use that kind if trick. If it returns
a positive number, there can be conflicts; if it returns a negative
number, then OPEN will reject that as there is nothing to tell the OPEN
to accept that it comes from an inquire and should be treated specially.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| James Giles 2007-01-22, 8:15 am |
| Gary Scott wrote:
....
>
> I personally don't consider that to be any better than an
> INQUIRE(FREEUNIT=ivar) method followed by a normal OPEN(UNIT...). I
> consider INQUIRE to be more natural, otherwise, you're having OPEN
> perform an implicit inquire with the NEWUNIT specifier. [...]
But the INQUIRE doesn't open the file. Suppose you INQUIRE for
a free unit but don't open it right away, You subsequently INQUIRE for
another free unit (and it returns the same value because it *is* still
free).
You then use the results of the two INQUIREs to open two separate(?)
files. Suppose you INQUIRE for a free unit, but don't open it right away
and some other procedure subsequently uses the same unit to open a
file before you get around to it? Etc.
> [...] It also
> allows you to INQUIRE a free unit without immediately
> opening/assigning to something.
But, what use is the unit if you're not opening a file with it? Why
do you need it before the OPEN? You can't read, write, print, close,
endfile, flush, wait, rewind, or backspace it until it's open. What
else is there?
--
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
| |
| Gary Scott 2007-01-22, 8:15 am |
| James Giles wrote:
> Gary Scott wrote:
> ...
>
>
>
> But the INQUIRE doesn't open the file. Suppose you INQUIRE for
> a free unit but don't open it right away, You subsequently INQUIRE for
> another free unit (and it returns the same value because it *is* still
> free).
> You then use the results of the two INQUIREs to open two separate(?)
> files. Suppose you INQUIRE for a free unit, but don't open it right away
> and some other procedure subsequently uses the same unit to open a
> file before you get around to it? Etc.
My assumption was that once you query it, it is a reserved (negative or
whatever) number that can't be used anywhere else regardless of whether
it actuall gets connected or not. If a second inquire occurs, it must
return a different number.
>
>
>
>
> But, what use is the unit if you're not opening a file with it? Why
> do you need it before the OPEN? You can't read, write, print, close,
> endfile, flush, wait, rewind, or backspace it until it's open. What
> else is there?
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
***** 5 Jan: Back from 7 days in Cozumel! *****
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Richard Maine 2007-01-22, 8:15 am |
| Gary Scott <garylscott@sbcglobal.net> wrote:
> My assumption was that once you query it, it is a reserved (negative or
> whatever) number that can't be used anywhere else regardless of whether
> it actuall gets connected or not.
I don't see how it would know what is "elsewhere". It is just a number.
How would any I/O statement know that you were using the number returned
from the inquire or from some conflicting use that happens to be the
same number.
I think you'd end up having to build a big structure of special-case
complexity to support that concept... and I don't know why. What is it
supposed to achieve to get a number ahead of time? Getting the number
from the OPEN seems so much more straightforward.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| robert.corbett@sun.com 2007-01-22, 8:15 am |
|
Pierre Asselin wrote:
> The problem here is not that the handle is numeric, but that the
> the responsibility for its value is forced on the user.
No, the problem is that it is numeric. The numeric value has to be
translated into a reference to the real data structure that contains
the necessary data. That requires using a global table to map
numbers to the corresponding data structures. In threaded code,
that means using locks. I have seen real world programs | | |