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

[Mark LeAir]

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.

-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<mailto:j3-bounces at mailman.j3-fortran.org>> on behalf of Mark LeAir via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Reply-To: General J3 interest list <j3 at mailman.j3-fortran.org<mailto: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<mailto:j3 at mailman.j3-fortran.org>>, j3 <j3 at j3-fortran.org<mailto:j3 at j3-fortran.org>>
Cc: Mark LeAir <mleair at nvidia.com<mailto: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<mailto: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<mailto:j3 at j3-fortran.org>>
Cc: Van Snyder <van.snyder at sbcglobal.net<mailto: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/197f7975/attachment-0003.htm>