However, I do not agree with Jeff's shortening scheme for
MPI_FILE_WRITE_EXPLICIT_ALL, ...
First of all, "X" commonly stands for extended, not explicit.
"A" is ambiguous, and could be interpreted for asynchronous.
And for shared, I bet "S" would be proposed. Unfortunately, "S" is already
used in MPI-1 for synchronous. Therefore, even if the long names
are ugly, I would rather keep them, as long as they are less than 31
characters long. Unfortunately, MPI_WRITE_SHARED_ORDERED_START
is already 30 characters long, and adding "FILE_" would make it too long.
Therefore, if we decide that "FILE_" should be added to be compliant
to the new naming rules for MPI-2, we must shorten the names.
Before worrying about finding a shortening scheme which is satisfactory,
I would like to know how many of us are strongly opposed to slightly
breaking the new naming rules (the same way they are already broken by
MPI_SEND). Personally, I am not opposed to it.
Jean-Pierre
squyres @ cse.nd.edu
04/09/97 08:32 AM
Please respond to squyres@cse.nd.edu
To: mpi-io @ mcs.anl.gov
cc: (bcc: Jean-Pierre Prost/Watson/IBM Research)
Subject: A bunch of IO issues
This was sent to mpi-io a few days ago, but I don't know if it made it
to the posting (it hasn't showed up in the mpi-io archive). If this is
a duplicate, please ignore.
----
A little background for the mpi-io people just joining this
discussion...
Having recently returned from the US military, I was set to the task of
proofing all the C++ bindings in MPI-2. In looking over the IO chapter,
Bill and I have exchanged a few e-mails on some topics. Here's one of
them below, (because he dared me to send it to the list), including my
latest response. :-)
Comments welcome.
----
Bill Nitzberg wrote:
> > The binding for MPI_OPEN is a bit of a problem. The OUT variable is
the > > MPI::File, so therefore it should not be "this". What if we
changed it > > to have the MPI::Comm as this, and returned the new
MPI::FILE?
> >
> > MPI::File MPI::Comm::Open_file(...) const
> >
> > This also changes the name to MPI_COMM_OPEN_FILE...
>
> I dare you to suggest changing MPI_OPEN to MPI_COMM_OPEN_FILE on
> the mailing list... I don't think they'll be much support.
You're probably right, but it's the Right Thing to do (pounding on my
bible). I believe that the whole forum agreed to the
"object_action_subset" format of names...
> How much of a problem is "bit of a problem"?
Well, just the fact that it won't be "object_action_subset". I believe
that there is even text in Appendix B that says
"New clarifications on the J&E rules on page 34 of the January text:
...
d. No exceptions that rationalize inconsistent method names."
The whole idea Eric's and my proposal was to have consistent names,
since MPI-1 was such a mess. We even have some name conflicts between
MPI-1 and MPI-2 because people weren't careful in MPI-1. While it has
made some names longer, we have the following rationalizations:
- Consistency. Something lacking in MPI-1.
- Avoidance of potential name clashes in the future.
- The scoping, while not important to the C and Fortran bindings, is
very relevant to the C++ bindings.
- The file IO names are long anyway. What's 5 more characters? ;-)
For the MPI_COMM_OPEN_FILE name, I point out the following:
- The MPI_Comm is the only MPI opaque IN object. Therefore it must be
scoped on the MPI::Comm object.
- Since the MPI::File object is being *created*, it simply cannot be
scoped (or named) with "FILE" in the "object" position.
- MPI_WIN_INIT (chapter 5) also creates a new MPI opaque object, and is
created from a MPI_COMM. After some e-mail discussion, it was decided
to change its name to MPI_COMM_CREATE_WIN, which is basically that same
thing that I'm proposing here.
-----
There is also the issue of the MPI_READ_* and MPI_WRITE_* functions.
They should really be MPI_FILE_READ_* and MPI_FILE_WRITE_* (since
MPI::File is the IN MPI opaque object, etc.). Bill raised the point in
an another e-mail that this would make some names horrendously long --
e.g. MPI_FILE_WRITE_EXPLICIT_ALL. Yuk!
How about abbreviating your names? MPI-1 did it with the MPI_?SEND and
MPI_?RECV routines, and also used "v" for "vector" in a bunch of
places. I know that you're already using MPI_?READ_* and MPI_?WRITE_*,
but what about for "all" and "explicit"? How about just "a" and "xa"?
For example:
MPI_FILE_?WRITE[X][A]
That would make your names a lot shorter. So much shorter, that we
could lengthen the right back up by putting "FILE_" in there (and they'd
*still* be shorter than the original)! ;-)
{+} Jeff Squyres
{+} squyres@cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to Notre Dame for 4 years and ended up staying for a
decade."