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

Van Snyder van.snyder at sbcglobal.net
Tue Mar 2 23:25:16 UTC 2021


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
> > 
> > 
> > 
> > 
> > 
> >  
> > 
> > 
> > Thanks,
> > 
> > 
> > Vipul Parekh
> > 
> > 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210302/45fc87c4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 39951 bytes
Desc: not available
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210302/45fc87c4/attachment-0001.png>


More information about the J3 mailing list