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

[Clune, Thomas L. (GSFC-6101)]

Hi Bill,

 

(Apologies – I only now noticed how you sign your name.   Somewhere I thought I saw you went by William.)

 

Tom:

 

I would argue that the template parameters at the module template level is not necessarily the union of all the template parameters used by the actual templated entities contained therein. If templated modules can contain templated modules or templated procedures then the instantiations of these components can be separately specified relying on their partial instantiation from the instantiation of the enclosing templated module. 

 

Did you mean “…can contain templated _derived types_ or …”?    Otherwise, I’m not sure what you meant above by “containe templated modules”.   (Introducing “inner modules” seems one solution to the specific matter under discussion, but that did not seem to be where you were headed.)     

 

Presuming I’ve understood correctly:   I am certainly not at all opposed to having template parameters at the module level.    I am merely hoping that they are not only at the module level.    And then, if types and procedures can have independent template parameters,  the value of parameters at the module level may be minimal.    However, the lesson of PDT’s still seems relevant.  How do we tie the parameters for a derived type template to the type-bound procedures that the language treats as independent entities on their own right?   I can easily imagine mechanisms, but have no idea if any are palatable.   Suggestions welcome.

 

There is no reason that a templated module should be any less flexible than a templated class in C++. However for compatibility with the existing language the same functionality will be wordier than in C++.

 

I’m good with that.    “Wordier” is possibly a significant understatement, but such is life.

 

So far your examples have naturally focussed on simple cases, which of course have been templated algorithms, that don’t necessarily benefit from templated modules and hence don’t provide analyses of the features of templated modules. To examine the features of templated modules it is best to examine a couple of templated containers. Note that my additions to https://github.com/j3-fortran/generics/blob/main/Use_cases_and_requirements.md included some at least partial examples of containers.

 

I agree that containers bring the issue forward in a way that procedures do not.    And we have very much been looking at containers, but not from this perspective.     The focus on how to express “restrictions” avoided discussions about how type-bound procedures would be associated with the template parameters of the containing derived type.   This thread has now brought that issue to the fore, and presumably will be a major topic of discussion in one of the next two generics meetings.   (First priority is probably just an assessment of the J3 reaction to the tutorials, of which this thread is just one element.)

 

Cheers,

 
Tom
 

Sincerely,

 

Bill



On Mar 9, 2021, at 7:02 AM, Clune, Thomas L. (GSFC-6101) via J3 <j3 at mailman.j3-fortran.org> 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.     Magne says that experience in other languages as that well-designed templates will encourage extensions and the module-level approach will lead to long lists that are more difficult to use.
Not a catastrophe.   But not ideal either.

If I understand correctly,  you are endorsing parameterized modules against other solutions.   None of which have yet been proposed.     The examples in the tutorials were not even intended to address this particular issue.  Rather they focused on small motivating examples for "restrictions" and potential ways to deal with the irregularities in existing Fortran syntax.    Granted, the examples put the template parameters on the types and the procedures, but that was not the intent per-se.  (I'll also grant that it does reveal a bias on the part of the presenters.)   If nothing else, that makes the examples smaller by a few lines each which is useful in PPT.

Cheers,

- Tom

<snip>

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210309/0198a99d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 9447 bytes
Desc: not available
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210309/0198a99d/attachment-0001.bin>