From owner-sc22wg5@dkuug.dk Tue Jun 24 01:43:25 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h5NNhPKV049750 for sc22wg5-domo; Tue, 24 Jun 2003 01:43:25 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from mail1.cray.com (mail1.cray.com [136.162.0.111]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5NNhGEc049745 for ; Tue, 24 Jun 2003 01:43:20 +0200 (CEST) (envelope-from longb@cray.com) Received: from relayb.mw.cray.com (relayb.us.cray.com [192.168.252.110]) by mail1.cray.com (8.12.9/8.12.3/gw-1.14) with ESMTP id h5NNh8lW001596; Mon, 23 Jun 2003 18:43:08 -0500 (CDT) Received: from saffron.us.cray.com (saffron.mw.cray.com [172.31.27.14]) by relayb.mw.cray.com (8.12.9/8.12.6/hub-1.2) with ESMTP id h5NNh6V9026824; Mon, 23 Jun 2003 18:43:06 -0500 (CDT) Received: from cray.com (mh-dhcp-172-31-16-133 [172.31.16.133]) by saffron.us.cray.com (8.8.8/Cray-server-1.6-nhsmod011017) with ESMTP id SAA4860588; Mon, 23 Jun 2003 18:43:06 -0500 (CDT) Message-ID: <3EF79229.7040302@cray.com> Date: Mon, 23 Jun 2003 18:50:01 -0500 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Van Snyder CC: sc22wg5@dkuug.dk Subject: Re: (SC22WG5.2798) Directions for Modules TR References: <200306210245.h5L2jPSY021832@math.jpl.nasa.gov> Content-Type: multipart/alternative; boundary="------------090802030109080404080407" X-Cray-VirusStatus: clean Sender: owner-sc22wg5@dkuug.dk Precedence: bulk --------------090802030109080404080407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van Snyder wrote: >>I'm not sure the rejection of SEPARATE was tied to the prefix issue as >>much as not liking the word at all. >> >> > >This is definitely the case. I believe that SEPARATE was rejected >hastily just because some folks didn't like the word on Thursday morning > > And at least some of us still don't like it. > > >>SEPARATE, as well as FORWARD (which is even worse in my opinion) are >>words that denote a spatial distinction. I would prefer words that >>indicated what a section of code is supposed to *be* rather than >>where it is. This is why I prefer the IMPLEMENTS proposal. >> >> > >I disagree with this analysis (except the part about FORWARD being worse >than SEPARATE). It simply demonstrates that we need to be careful to >define precisely how we use common-usage words, and how we want the >reader to think about them. I don't think of SEPARATE as meaning >primarily that the reader has to look elsewhere. I chose SEPARATE >because it is exactly the right word: It tells both the reader and >processor that the interface and implementation are expressed >separately. It doesn't say "where," it says "what." > I think you've just proved my point. I had thought SEPARATE meant something different, that the interface was in a separate module/submodule from the implementation. The concept of "the interface and implementation are expressed separately" applies equally well to old-fashioned interfaces for external functions. SEPARATE does not make a connection to the submodule idea. At least not for me. > > > >>There have been two objections to this proposal so far (both from Van). >>One was trivial. The other was that the lack of a prefix word in the >>submodule does not provide a prefix to be used in the interface in the >>parent, implicitly assuming that a prefix is needed in the parent. I >>don't see this as a reason to reject the IMPLEMENTS idea, but rather a >>reason to develop a better solution in the parent. >> >> > >I didn't object specifically to the IMPLEMENTS idea, except if it is >proposed to allow only one IMPLEMENTS section and one CONTAINS section, >with a specific ordering requirement, say IMPLEMENTS first and CONTAINS >second. I did not see this as a trivial objection. I will not do a TR >that has this monstrosity. > But, pretty clearly to me, what is intended is exactly that there be only one IMPLEMENTS and one CONTAINS, in that order. The only objection I've seen to that regarded alphabetical ordering of the routines. This is insignificant at best. If the majority of WG5 really believe that the inability to arrange all of the implemented and contained routines in a merged alphabetical list is grounds for canceling the TR, I'd be very disappointed. The basic idea behind submodules is more valuable than this. > > > >>I don't recall why SUBMODULE INTERFACE was rejected before, but at >>that would be one option to consider. At least it connects to the >>idea of submodules. >> >> > >SUBMODULE INTERFACE was rejected because the procedure body might be in >the module. > I hope I'm misunderstanding that statement, We certainly don't want to allow the procedure body in the parent module. Putting the procedure body in the same module as the interface defeats the whole point of submodules. It also makes the design unnecessarily complicated, not to mention confusing for users. We already have syntax and rules for procedures defined in a module. They work just fine. > > > >>If you prefer something attached to the subprogram statement rather than >>the interface statement, something similar to the bind(c) syntax might >>work, such as >> >>interface >> subroutine sub(x,y),implemented_in(submodule_name) >>... >>end interface >> >>Either of these options communicate to the user what is going on more >>clearly that SEPARATE or FORWARD. The implemented_in(submodule_name) >>would allow for an extra measure of verification by the compiler that >>you are doing what you intended. It also might make the name mangling >>algorithm easier. >> >> > >Doesn't this say where it is, not what it is? > It says both, which is more that I got from the prefix. > >Processors already use the program unit where a module's interface is >defined for name mangling. Would you go to the extra work to do >something different if it wasn't really necessary? > That's only half the story. The processor (at least ours) also puts the location of the module procedure object code into the header of the object file for the routine that uses the module. This allows the linker to find the object code for the module procedure. It is still not clear to me how we're going to implement this in the submodule environment. At a minimum, the implemented_in( ) syntax spells out for the user what is going on, and where he should look for the definition of the procedure. This would be helpful in trying to debug code. It also avoids the problems with in general that have been raised by others. Cheers, Bill > >-- >Van Snyder | What fraction of Americans believe >Van.Snyder@jpl.nasa.gov | Wrestling is real and NASA is fake? >Any alleged opinions are my own and have not been approved or disapproved >by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else. > > -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120 --------------090802030109080404080407 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van Snyder wrote:
I'm not sure the rejection of SEPARATE was tied to the prefix issue as 
much as not liking the word at all.
    

This is definitely the case.  I believe that SEPARATE was rejected
hastily just because some folks didn't like the word on Thursday morning
And at least some of us still don't like it.
  
SEPARATE, as well as FORWARD (which  is even worse in my opinion) are
words that denote a spatial  distinction.  I would prefer words that
indicated what a section of code is supposed to *be* rather than
where it is.  This is why I prefer the IMPLEMENTS proposal.
    

I disagree with this analysis (except the part about FORWARD being worse
than SEPARATE).  It simply demonstrates that we need to be careful to
define precisely how we use common-usage words, and how we want the
reader to think about them.  I don't think of SEPARATE as meaning
primarily that the reader has to look elsewhere.  I chose SEPARATE
because it is exactly the right word:  It tells both the reader and
processor that the interface and implementation are expressed
separately.  It doesn't say "where," it says "what."

I think you've just proved my point.  I had thought SEPARATE meant something different, that the interface was in a separate module/submodule from the implementation.  The concept of "the interface and implementation are expressed separately" applies equally well to old-fashioned interfaces for external functions.  SEPARATE does not make a connection to the submodule idea. At least not for me.

  
There have been two objections to this proposal so far (both from Van).
One was trivial.  The other was that the lack of a prefix word in the
submodule does not provide a prefix to be used in the interface in the
parent, implicitly assuming that a prefix is needed in the parent.  I
don't see this as a reason to reject the IMPLEMENTS idea, but rather a
reason to develop a better solution in the parent.
    

I didn't object specifically to the IMPLEMENTS idea, except if it is
proposed to allow only one IMPLEMENTS section and one CONTAINS section,
with a specific ordering requirement, say IMPLEMENTS first and CONTAINS
second.  I did not see this as a trivial objection.  I will not do a TR
that has this monstrosity.

But, pretty clearly to me, what is intended is exactly that there be only one IMPLEMENTS and one CONTAINS, in that order.  The only objection I've seen to that regarded alphabetical ordering of the routines.  This is insignificant at best.  If the majority of WG5 really believe that the inability to arrange all of the implemented and contained routines in a merged alphabetical list is grounds for canceling the TR, I'd be very disappointed.  The basic idea behind submodules is more valuable than this.


  
I don't  recall why SUBMODULE INTERFACE was rejected before, but at
that would be  one option to consider. At least it connects to the
idea of submodules.
    

SUBMODULE INTERFACE was rejected because the procedure body might be in
the module.

I hope I'm misunderstanding that statement, We certainly don't want to allow the procedure body in the parent module.  Putting the procedure body in the same module as the interface defeats the whole point of submodules.  It also makes the design unnecessarily complicated, not to mention confusing for users.  We already have syntax and rules for procedures defined in a module. They work just fine.


  
If you prefer something attached to the subprogram statement rather than 
the interface statement, something similar to the bind(c) syntax might 
work, such as

interface
  subroutine sub(x,y),implemented_in(submodule_name)
...
end interface

Either of these options communicate to the user what is going on more 
clearly that SEPARATE or FORWARD.  The implemented_in(submodule_name) 
would allow for an extra measure of verification by the compiler that 
you are doing what you intended. It also might make the name mangling 
algorithm easier.
    

Doesn't this say where it is, not what it is?

It says both, which is more that I got from the prefix.

Processors already use the program unit where a module's interface is
defined for name mangling.  Would you go to the extra work to do
something different if it wasn't really necessary?

That's only half the story. The processor (at least ours) also puts the location of the module procedure object code into the header of the object file for the routine that uses the module. This allows the linker to find the object code for the module procedure.  It is still not clear to me how we're going to implement this in the submodule environment.   At a minimum, the implemented_in( ) syntax spells out for the user what is going on, and where he should look for the definition of the procedure.  This would be helpful in trying to debug code.  It also avoids the problems with <prefix> in general that have been raised by others.

Cheers,
Bill


--
Van Snyder                    |  What fraction of Americans believe 
Van.Snyder@jpl.nasa.gov       |  Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or disapproved
by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.
  

-- 
Bill Long                                   longb@cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

--------------090802030109080404080407--