You must have missed part of my message. As I said, the above:
1. solves the parsing problem
2. is not what had actually been proposed, by my reading
3. is not a string proposal, but an "array of strings" proposal.
While it doesn't have any serious limitations, it also
does not seem to be superior to language facilities
for "array of strings", namely **char[] in C and
character*(*) a(n, *) in Fortran. The language
constructs are about as complex to use.
That's why I would prefer the language arrays, which
are not actually that complicated. The nastiest
example mentioned has always been the _multiple case
for Fortran, where you have 2-D arrays of character
strings, and when you actually work through it, it turns
out not to be too bad - example at the end of this note.
One idea that I don't think has been discussed but which
I think simplifies enormously is to separate the "command"
from the "arguments" as PVM does. Then 99% of the time
the user just types "foo" for the command - no need
to deal with array_of_string objects or the language
equivalent. Just "NULL" or "MPI_ARG_NULL" for the
arguments. One reason we rejected the argv approach
was that we imagined the command as the first
element of argv, so that the user would always have to
deal with some nastiness. BTW, I favor NULL-terminated
argv in C and ' '-terminated argv in Fortran. No argc
necessary.
There are actually two minor issues I'm aware of with
the language arrays of strings in Fortran:
1. no way to specify an empty argument (who cares?) since
the end-of-arguments marker is probably the empty string.
2. you have to declare the first dimension of your array to
be the actual number of commands - you can't "overdeclare"
The "trailing spaces are discarded" issue is there in any
proposal.
As for the "info" and "hint" case, I still slightly prefer
the key/value-based info proposal from the last meeting. It
can never hurt to have objects that accurately represent
your actual data structure. For instance, I can inquire
about the value of "key"; I can duplicate the structure
and replace certain values (very useful for multiple commands
with nearly identical infos); I can even have a key with "="
in it. It also avoids little parsing nasties like "key = value"
(setting the key to "key " and the value to " value").
Different parts of an application can fill in different parts
(e.g., the "machine specific" part and the part that fills
in the MPI-reserved keys. ). Nice all around (except that it
can't be applied to the command_line :-).
Oh, and I wouldn't be unhappy with the original
proposal of a single string with key=value separated by whitespace.
> I got a feeling at the meeting that some people like the idea of
> on-the-fly parsing of the info object, ...
I agree with your comments. If we have an info object it will
probably not be possible to parse on the fly.
> I don't like the solution of using argc/argv for C and something
> different for F77 because it's a departure from the "keep the API the
> same" position.
I agree. Fortunately, Fortran seems to be able to handle argv with no
problem. See below.
> Bill, this is like saying that foo.c is not an ASCII file or that
> stdin/out are not streams of characters. :-)
That's right. In user-friendly operating systems, foo.c is a C
program, not only an ASCII file, and the information that it is a C
program (and what application should be called, what icon should be
displayed, etc) is stored somewhere other than the extension. Mac OS
and MIME are good examples of the general principle.
stdin/out, on the other hand, are really streams of characters - this
is the Unix way.
As you say, none of this is really a show-stopper for dynamic. All of
the proposals could probably work. The most important thing to
resolve is probably the merger with the IO chapter proposal, and
perhaps we should see what naturally comes out of that.
Bill
ps. So here's the Fortran example for the most complicated case.
program foo
implicit none
integer ncommands, max_args
parameter (ncommands=3, max_args=5)
c Each arg list has max of five args. There are three arg lists
c args(i, j) is jth arg of ith arg list.
c note: this seems the reverse of "natural" fortran ordering
c but is necessary because we pass number of arg lists in command line
character*(25) args(ncommands, max_args)
character*(25) command_lines(ncommands)
c build 3 command lines
c foo -arg1 -arg2
c bar (no args)
c baz d1 d 2 d3 (middle arg is "d 2")
command_lines(1) = ' foo'
args(1, 1) = '-arg1 '
args(1, 2) = '-arg2 '
args(1, 3) = ' '
command_lines(2) = ' bar'
args(2, 1) = ' '
command_lines(3) = ' baz'
args(3, 1) = 'd1'
args(3, 2) = 'd 2'
args(3, 3) = 'd3'
args(3, 4) = ' '
call mpi_foo_multiple(command_lines, args, ncommands)
stop
end
subroutine mpi_foo_multiple(command_lines, args, n)
implicit none
integer n
character*(*) command_lines(n)
character*(*) args(n, *)
integer i, j
do i = 1, n
write(6, 100) i
100 format(' Command line ', i3, ':')
write(6, 101) command_lines(i)
101 format(' Command : ', a10)
write(6, 102)
102 format(' Arguments: ')
do j = 1, 100
if (args(i, j) .eq. ' ') goto 1000
write(6, 103) j, args(i, j)
103 format(' ', i4, ": ", a10)
end do
1000 continue
end do
return
end