From owner-sc22wg5@dkuug.dk  Sat Jun 21 21:15:50 2003
Received: (from majordom@localhost)
	by dkuug.dk (8.12.8p1/8.9.2) id h5LJFoaN037957
	for sc22wg5-domo; Sat, 21 Jun 2003 21:15:50 +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 Princeton.EDU (root@postoffice02.Princeton.EDU [128.112.130.38])
	by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5LJFgEc037952
	for <sc22wg5@dkuug.dk>; Sat, 21 Jun 2003 21:15:45 +0200 (CEST)
	(envelope-from adonev@Princeton.EDU)
Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65])
	by Princeton.EDU (8.12.9/8.12.9) with ESMTP id h5LJFear009149
	for <sc22wg5@dkuug.dk>; Sat, 21 Jun 2003 15:15:40 -0400 (EDT)
Received: from princeton.edu (atom.Princeton.EDU [128.112.143.9])
	(authenticated bits=0)
	by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id h5LJFe0k011765
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <sc22wg5@dkuug.dk>; Sat, 21 Jun 2003 15:15:40 -0400 (EDT)
Message-ID: <3EF4AEDC.2000905@princeton.edu>
Date: Sat, 21 Jun 2003 15:15:40 -0400
From: Aleksandar Donev <adonev@Princeton.EDU>
Organization: Princeton Materials Institute, Princeton University
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sc22wg5@dkuug.dk
Subject: Re: (SC22WG5.2798) Modules TR syntax
References: <200306202321.h5KNLroJ030959@dkuug.dk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-sc22wg5@dkuug.dk
Precedence: bulk

Hello,

>I got four not-very-convincing responses.
>
I have to say that your responses have not been very convincing 
either..."I like to alphabeticize my procedures" hardly counts as one.

First, a question for Lawrie, who wants to introduce submodule association:
A separate procedure can be in the same module, in which case it 
accesses the module via host association. Do you propose to change this 
for such procedures, so that redeclarations of module entities in the 
procedure body mean something else?

Now, here is a summary of what I consider significantly better syntax 
then the current draft, or Lawrie's proposal, but which tries to account 
for those proposal's ideas and worries. Of course, all is IMO, and 
others can decide the merit of it all. But you are correct in assuming 
that not many will think about this before the meeting itself :-(

MODULE My_Module

IMPLEMENTATION INTERFACE
! In this kind of interface host association is automatic
! IMPORT is not allowed
INTEGER FUNCTION Function_1(x)
INTEGER :: x
END FUNCTION
REAL FUNCTION Function_2(x)
REAL :: x
END FUNCTION
END INTERFACE

INTERFACE My_Generic
MODULE PROCEDURE :: Function_1, Function_2, Function_3
! These are all module procedures
! We should allow here I believe in 260:27
CHARACTER FUNCTION Function_4(x) ! External
IMPORT ! OK here
CHARACTER :: x
END FUNCTION
END INTERFACE

IMPLEMENTS
! Special association may apply within the IMPLEMENTS block
! But they better be the same as in the SUBMODULE below!
! I personally would prefer to keep host association for simplicity...

IMPLEMENTATION PROCEDURE(Function_2)
! No redeclaration at all
! This is my preference, but not necessary
! I would also agree with requiring full redeclaration
Function_2=x*x
END IMPLEMENTATION

CONTAINS

CHARACTER FUNCTION Function_4(x)
CHARACTER :: x
Function_4=x
END FUNCTION

END MODULE

SUBMODULE(My_Module) My_Submodule
! Association rules with My_Module entities is to be determined
! by Van and Lawrie bout

IMPLEMENTS

INTEGER FUNCTION Function_1(x) ! Full-redeclaration
! Or no redeclaration as above
INTEGER :: x
Function_1=x*x
END FUNCTION

END SUBMODULE

Notice that I have used the work IMPLEMENT as the root of the two new 
keywords, IMPLEMENTATION and IMPLEMENTS. This seems to me the most 
natural choice.

The only blot in this is that for the generic interface My_Generic, one 
has to retype the names of the procedures Function_1, Function_2 etc. 
But notice that their interface is only declared once, in the 
IMPLEMENTATION INTERFACE. I consider this a minor annoyance, and will 
propose generic interface merging for the next revision which will fix 
this and other annoyances with generic interfaces.

>I don't want to be sandbagged on this issue, like I was at the Oxford J3
>meeting concerning a procedure to get error message text given an IOSTAT
>value.
>
My interest and will to contribute to the discussion should in no way be 
taken as an attempt to "sandbagg" you. I greatly appreciate your work on 
this. The main ideas are great and this is the essence of the proposal. 
But I do not like your approach to the syntax, and of course it is my 
right to disagree.

Best,
Aleksandar