Subject: Proposal to add declarative MODULEs to HPF

From: [email-masked]
Date: Fri, 12 Jun 92 18:18:05 CDT

During the June HPFF mtg the issue of local versus globally available names
arose in several ways:

   a.  Sequence and Storage Association (``SSA'').

	Group 1's proposal provided two forms of named COMMON.  One form
	may only hold individually distributed objects.  The other form
        is essentially identical to that of F77: all objects within it
        cannot be individually distributed, but full SSA applies to the
	entire block.  A modification of this proposal by Andy Meltzer
	to permit the SSA block to be distributed as a single entity
	was accepted.

	Ken Kennedy entered an alternative proposal in which there
	is only one form of named COMMON.  This COMMON can intermix objects
	that are individually distributed with ``sequential'' objects 
	on which full SSA is available.  The user is required to ensure
        that the intermixing is consistent across subprograms.  In particular,
	that sequential objects and individually distributed objects do
	not ``overlap'' across subprogram units.

   b.  The status of the names of TEMPLATEs and of PROCESSOR arrangements is
       not well defined.  They are declared within a subprogram and exist only
       within that subprogram.  They cannot be passed as arguments and cannot
       be placed in COMMON.  Thus, we have language entities with similar
       usage to F90 derived types that only exist within a single subprogram
       (not just their names, but the actual entity!).

 Matthijs van Waveren has pointed out that the F90 MODULE is the appropriate
 solution for these problems.  A MODULE provides a mechanism to make object names
 globally available without the semantic baggage of a COMMON block.  Furthermore,
 because F90 derived types may appear in a MODULE, this is the right way to
 make TEMPLATE and PROCESSOR arrangement names globally available.

 However, vendors in the HPFF meetings have indicated that the F90 MODULE 
 represents substantial implementation overhead.  Thus, in keeping with 
 both our commitment to F90 as the base language, and our goal of timely
 HPF definition and availability, I propose that we *require* a specification-part
 only form of the F90 MODULE.  (See below for details.)  Vendors are, of course,
 free to implement other MODULE functionality.

 **********************************************************************

 Proposal:    Require F90 MODULE specification part and renaming facility.
	      
	      All COMMON blocks should have full F77 SSA, and be distributable
	      as a single entity.

 **********************************************************************

 Module definition:
 -----------------

	MODULE module-name
	  specification statements
	END [ MODULE [ module-name ] ]

   Where ``specification statements'' are those of F90 augmented with
   those of HPF.

   Example:

	MODULE named_common_1
	   INTEGER , PARAMETER :: N = 1024

CHPF	   TEMPLATE grid_points ( N , N )
	   REAL , ARRAY( N , N ), ALIGN WITH grid_points :: bug_count_per_grid_point

	END MODULE named_common_1

C The names available from this module are:  N , grid_points , bug_count_per_grid_point

 Module use:
 ----------

	USE module-name [, rename-list ]

   This statement is placed ahead of the specification statements within
   program units that employ a module.  The rename-list capability permits
   an entity within the module to be identified by another name within the
   subprogram unit in which the USE statement appears.  Thus, the renaming 
   ``facility'' of COMMON can be mimicked.

   Example:

	SUBROUTINE report_them_all
	
	    USE named_common_1 , N_GRID_POINTS => N
	    bug_count_per_grid_point = bug_count_per_grid_point + 1
	
        END SUBROUTINE report_them_all

 For discussion:

   .  How much additional work will this require of vendors ?  Is this
      outweighed by simplification elsewhere ?

   .  Entities within modules can be declared PUBLIC or PRIVATE.  (The default
      can be set at the head of the module.)  Should this functionality also be
      required ?  I'm inclined to say yes, because then TEMPLATEs and PROCESSOR
      arrangement names can be hidden.

Peter