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

[Shterenlikht, Anton]

Tom

I'd prioritise simplicity over the ability
to cover every possible use case.

I understand how parametrised modules should work
(or parametrised procedures, but modules seem
a better alternative).
I'd call param modules a "simple" and clear solution.

If a majority of use cases can be done with param modules,
I would support that approach, even if we reject
e.g. the use PDT, and other existing obj oriented features there.

If a certain class of problems cannot be
addresses via param modules, but most existing use
cases can - I'd still support the param modules
as the solution.

I think it virtually impossible to find a generics
solution that will support all existing obj
oriented language features and is simple.

Thank you (and the generics sub-group).

Anton


> On 8 Mar 2021, at 14:00, Clune, Thomas L. (GSFC-6101) via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> Hi Van,
>  
> Thank you – this 2nd response is far more constructive.     And yes, if I had ever understood just how PDT’s were broken, I had long since forgotten.   Your reminder below is well taken, and any solution for templates must properly account for these concerns.
>  
> Parameterized modules definitely does address this particular concern, but at the same time it raises other concerns about the need to aggregate template parameters across all the contained entities.    These are of course lesser concerns than the one you raise, but are sufficient for us to desire alternatives which allow treatment the template parameters at a finer granularity.     
>  
> As I mentioned before, generics subgroups already recognizes that parameterized modules is a relatively complete approach and there has been no sense of outright rejection of that approach.   (New thumbprints are of course inevitable.)      In many senses, we are still in the phase of learning why all the alternatives don’t work.       As our plans become more concrete,  I strongly encourage you to identify problems and concerns.       Ideally, working out the implementation of use cases will identify problems along the one in this thread very early in the process.   But no filter is perfect, and we want many eyes on this.
>  
> Generics subgroup is both highly motivated and very intimidated by the challenge of getting this right.
>  
> 	• Tom
>  
>  
> From: Van Snyder <van.snyder at sbcglobal.net>
> Date: Tuesday, March 2, 2021 at 6:27 PM
> To: j3 <j3 at j3-fortran.org>
> Cc: "Clune, Thomas L. (GSFC-6101)" <thomas.l.clune at nasa.gov>
> Subject: Re: [EXTERNAL] Re: [J3] Slides available for your preview - Part 2 of the Generics Tutorial today at the J3 plenary
>  
> On Tue, 2021-03-02 at 21:05 +0000, Clune, Thomas L. (GSFC-6101) wrote:
>> Disagree that it is the only way.    But agree that it is one way.
>>  
>> I have some concerns about the parameterized modules approach,  but we may well end up there.  
>>  
>> For the moment we are exploring and your argument below that “One needs to have generic encompass everything in a module.” Is unsubstantiated.  (And a bit hard to believe given approaches in other languages.)
>  
> If you prepare a parameterized type with type-bound procedures, you necessarily must (at present) prepare a collection of those procedures with arguments having a spectrum of kind type parameters that you expect will be used when objects of that type are declared.
>  
> If you don't provide all those procedures, somebody will eventually declare a variable having a spectum of kind type parameters for which the code won't even compile. Richard Maine complained about this twenty years ago. He said only that we hadn't integrated parameterized derived types with type-bound procedures, but didn't explain the problem in detail, apparently assuming it was too obvious to need explanation.
>  
> I don't see how to prevent that problem other than by encapsulating the type, and its type-bound procedures, in a single entity, and using parameters of that entity to specify kind type parameters of the type and arguments of its type-bound procedures. The obvious entity is a simple extension of modules. There is no reason to introduce an entirely new concept to Fortran. Separately parameterized types and procedures might go some distance, but that strategy isn't integrated, and is inherently fragile. It would still be too easy to leave out some combinations.
>  
> If we insist on pursuing other methods, I'd like to see a cogent description how to avoid that problem with those arrangements, not vague handwaving and words such as "template." The failure of parameterized procedures to address that problem, as well as the obvious conclusion that parameterized procedures are immanent in parameterized modules, is the reason we rejected pursuit of parameterized procedures.
>  
> Indeed, if parameterized modules had existed in 1997, I believe it is unlikely we would have developed parameterized derived types, at least not ones parameterized by kind parameters. There would have been no point. And types and type-bound procedures would have been integrated right out of the box, instead of their integration sitting in limbo for a quarter century. Another big failure of parameterized derived types was failure to parameterize them with types. That comes automatically with parameterized modules.
>  
> The technology to process the equivalent of parameterized modules has been in place for nearly forty years. Ada '83 provided generic packages, which amount to the same thing. There is a web page that describes the simple method that the GNU Ada Translator uses to instantiate generic packages by abstract syntax tree transformation. They don't change the structure of the tree. They just copy it, and annotate its vertices using package parameters to make it look like the internal representation of a non-generic package. The method I described seventeen years ago in 04-383r1, of a USE statement that specifies parameters, creating an instance of a parameterized module, could be implemented the same way.
>  
> Fortran development has a long history of half-measure compromises, that have preserved what was described in 1980 as "Fortran's beloved tacked-on look."
>  
> Please do it comprehensively and correctly this time around. Do it in the context of Fortran structure and idioms, not by tacking on something from another language that is essentially incompatible.
>  
>>  
>> -          Tom
>> -           
>>  
>> From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of Van Snyder via J3 <j3 at mailman.j3-fortran.org>
>> Reply-To: General J3 interest list <j3 at mailman.j3-fortran.org>
>> Date: Tuesday, March 2, 2021 at 3:30 PM
>> To: "j3 at mailman.j3-fortran.org" <j3 at mailman.j3-fortran.org>
>> Cc: Van Snyder <van.snyder at sbcglobal.net>
>> Subject: [EXTERNAL] Re: [J3] Slides available for your preview - Part 2 of the Generics Tutorial today at the J3 plenary
>>  
>> This approach to generic is wrong headed. It is not useful to have "generic" encompassing a few requirements. One needs to have generic encompass everything in a module. Otherwise, the incomplete and inconsistent integration of parameterized types and type-bound procedures, about which Richard Maine warned twenty years ago, is not addressed.
>>  
>> Go back and look at 04-383r1. It addresses all of the issues that Magnus discussed in Tokyo.
>>  
>> On Tue, 2021-03-02 at 13:42 -0500, Vipul Parekh via J3 wrote:
>>> Fyi, a copy of the slides for part 2 of the tutorial on Generics is available, if you're interested in taking a look ahead of today's meeting.
>>>  
>>> It is under Meeting FIles -> Tutorials and file named, "Part 2 Tutorial Generics.pdf":
>>> https://j3-fortran.org/meetingfiles/ws-meeting-files/Tutorials
>>> <image001.png>
>>>  
>>> Thanks,
>>> Vipul Parekh