[J3] [EXTERNAL] Re: Re: Slides available for your preview - Part 2 of the Generics Tutorial today at the J3 plenary

Wed Mar 10 22:49:00 UTC 2021

On Wed, 2021-03-10 at 18:00 +0000, Mark LeAir via J3 wrote:
> Hi Tom,
> 
>  
> 
> I am asking about modules that can take other modules as parameters.
> I don’t know why this would complicate dependency generators in build
> systems since they already have to deal with “modules that use other
> modules”.  Sure, a parameterized
>  module is slightly different from a traditional module, but from a
> dependency generator point of view, it should not be that much
> different than a “module that uses another module”.
> 
>  
> 
> I don’t know why there would be difficulties allowing “module names
> as parameters”. However, to simplify things, we could have the notion
> of a generic module and a nongeneric module as described in Van’s
> paper (04-383r1).
> 
> 
>  
> 
> The generic module could be a parameter to a traditional (or
> nongeneric) module. I’m not opposed to calling these entities
> something else (e.g., “template” instead of “generic module”). Van’s
> paper also mentions “Generic Parameters as generic
>  or nongeneric modules” in section 8.4.4. Maybe allowing “generic
> modules as module parameters” (and disallowing “nongeneric modules as
> module parameters”) is sufficient and avoids your concern over
> “module names as parameters” since “generic modules” would
>  be a new construct to the language.

There is no problem in allowing either a generic module name or a non-
generic module name as a parameter to an instantiation of a generic
module. Of course, within the generic module's definition, there is a
specification of the characteristics of its parameters, including the
parameters of any parameter that is a generic module. This is no
different from a procedure having the characterists of its dummy
procedures, and if those dummy procedures have dummy procedures, the
characteristics of those.... Current syntax allows nested interface
blocks. This is nothing new.
A generic module can USE a non-generic module that is not a parameter.
The processor accesses that module when it processes the generic module
as such, not when it is instantiated.

A generic module can have a parameter that is a non-generic module.
When it is instantiated, the parameter can be an instance of a generic
module, which is a non-generic module once it is instantiated. This is
not a problem.

If a parameter is a non-generic module, all that can be done within the
generic module is for its name to appear in a USE statement, or as the
parameter to another generic module. This does not access it. An
instance of the generic module that has a non-generic module as a
parameter accesses the module that is a parameter. This does not
complicate dependency analysis because the non-generic module does not
get USEd in the generic module, only in an instance of it, when the
dependency-analyzer has access to the actual parameter at the point of
instantiation. The scheme that is ultimately developed would benefit by
having a specification of requirements on entities accessed from that
module parameter by USE association, essentially an interface block, by
a different name. A USE statement for a non-generic module parameter
should be required to have an ONLY clause so that requirements for the
accessed entities can be specified.
If a parameter is a generic module, the only thing the generic module
of which it is a parameter can do is put it again as a module
parameter, or specify that the parameter is instantiated when the
generic module is instantiated. It does not, of course, get
instantiated in the generic module, only in a specific instance of it.
Of course, a generic module can instantiate a generic module that is
not a module parameter. This occurs when the generic module is
processed as such, not when it is instantiated. For example, a generic
module might need an INTEGER sort routine, or a list of objects of a
non-generic type it defines, or ..., not a generic one.
Instantiation of a generic module that has a generic module (not an
instance of one) as a parameter is a recursive process. Computer
science mastered recursion about sixty years ago.
>  
> -Mark
>  
>  
> 
> 
> From: Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov>
> 
> 
> Sent: Wednesday, March 10, 2021 5:40 AM
> 
> To: General J3 interest list <j3 at mailman.j3-fortran.org>; j3 <
> j3 at j3-fortran.org>
> 
> Cc: Mark LeAir <mleair at nvidia.com>
> 
> Subject: Re: [J3] [EXTERNAL] Re: Re: Slides available for your
> preview - Part 2 of the Generics Tutorial today at the J3 plenary
> 
> 
>  
> 
> 
> 
> 
> External email: Use caution opening links or attachments
> 
> 
> 
> 
> 
>  
> 
> Hi Mark,
>  
> Hmm.  I think I understood (and even liked) the notion of “internal
> modules” that Bill Clodius mentioned earlier.     I think there might
> be some real difficulties in having module names as parameters.    At
> the very least, dependency generators
>  for the build system would be complicated.   Or have I misunderstood
> what you meant?
>  
> 
> Tom
>  
>  
> 
> From:
> J3 <j3-bounces at mailman.j3-fortran.org> on behalf of Mark LeAir
>  via J3 <j3 at mailman.j3-fortran.org>
> 
> Reply-To: General J3 interest list <j3 at mailman.j3-fortran.org>
> 
> Date: Tuesday, March 9, 2021 at 5:49 PM
> 
> To: General J3 interest list <j3 at mailman.j3-fortran.org>, j3 <
> j3 at j3-fortran.org>
> 
> Cc: Mark LeAir <mleair at nvidia.com>
> 
> Subject: Re: [J3] [EXTERNAL] Re: Re: Slides available for your
> preview - Part 2 of the Generics Tutorial today at the J3 plenary
> 
> 
>  
> 
> Van mentioned:
>  
> Is the "plethora of parameters" problem an artifact of mashing
> together things that aren't really related, or an artifact of
> extending something by adding somthing else,
> that needs the same parameters, and a few others?
> 
> 
>           It seems to me that this could be addressed by
> instantiating simpler parameterized modules within a parameterized
> module, to make a synthesis of several.
>  
> 
> 
> Yeah, I have been wondering if we also allowed modules to be
> parameterized by other modules, then this might address the concern
> of long parameter lists in parameterized modules. That is, the
> module-parameter could encapsulate parameters needed by the
> parameterized
>  module. These module-parameters could also be reused across multiple
> parameterized modules if one desired.
> 
>  
>  
>  
> -Mark
>  
>  
>  
>  
>  
> 
> 
> From: J3 <j3-bounces at mailman.j3-fortran.org>
> On Behalf Of Van Snyder via J3
> 
> Sent: Tuesday, March 9, 2021 1:17 PM
> 
> To: j3 <j3 at j3-fortran.org>
> 
> Cc: Van Snyder <van.snyder at sbcglobal.net>
> 
> Subject: Re: [J3] [EXTERNAL] Re: Re: Slides available for your
> preview - Part 2 of the Generics Tutorial today at the J3 plenary
> 
> 
>  
> 
> 
> 
> 
> External email: Use caution opening links or attachments
> 
> 
> 
> 
> 
>  
> 
> 
> On Tue, 2021-03-09 at 14:02 +0000, Clune, Thomas L. (GSFC-6101)
> wrote:
> 
> > Anton,
> >  
> > 
> > It is not that parameterized modules cannot address the use
> > cases.      The problem is simply that the list of template
> > parameters at that level is the union of all template parameters
> > used by the actual templated
> >  entities contained therein.     
> > 
> 
>  
> 
> 
> This sounds like an artifact of a careless design.
> 
> 
>  
> 
> 
> If one needs to get only a bit of stuff from a parameterized module,
> and it's tangled with a lot of other stuff, the parameterized module
> was designed incorrectly.
> 
> 
>  
> 
> 
> Is the "plethora of parameters" problem an artifact of mashing
> together things that aren't really related, or an artifact of
> extending something by adding somthing else, that needs the same
> parameters, and a few
>  others?
> 
> 
>  
> 
> 
> It seems to me that this could be addressed by instantiating simpler
> parameterized modules within a parameterized module, to make a
> synthesis of several.
> 
> 
>  
> 
> 
> I agree that one might get a "combinatorial explosion." If one has N
> parameterized modules, each with a roughly-independent but slightly-
> overlapping set of parameters, there are 2^N ways to combine them
> into yet
>  another parameterized module. Actually probably somewhat less,
> because of overlap. If there's no overlap, there's no reason to
> package the smaller bits together.
> 
> 
>  
> 
> 
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210310/348074fc/attachment-0001.htm>