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

Mon Mar 8 21:05:12 UTC 2021

Hi William,

As promised -  a few follow-up comments.

As with Van’s email, you have correctly identified that there is a problem with my desire to put template parameters directly on types.  And as you say some additional language mechanism would be needed to accomplish this.     I can imagine a few different approaches, but we could lump them all into the category of introducing something a bit more like a C++ class.  And as you say the language is already big …   But I will pose this as a challenge to the generics subgroup.        I am glad that you see value in still having additional template parameters at the procedure level.    As mentioned in my email response to Van that seems to be the best compromise that I can currently envision.

Much of the discussion in generics subgroup thus far has been focused on the “syntactical complications” that you list.    Indeed, Vipul’s presentation was an initial attempt at showing that there are possible approaches to encapsulate the complications, at least to some extent.    If we can’t at least get TKR encapsulation as a single parameter, then I think the feature will be either cumbersome or limited in practice.    

A slightly different approach that Magne Haveraaen and I have played around with would be to introduce special templates that encapsulate some of the syntactical complications.     In some sense these can be thought of as automating the wrapper derived types that many of us now do on autopilot any time we want array of something that cannot be an array.   The trick to making this useful will be to allow the wrapped types to act as the contained type in contexts where that is useful outside the template but to act as very simple scalar entities within templates.      Something similar may be needed to encapsulate intrinsic types to create near-intrinsic types that work like a simple derived type inside of a template, but can be used interoperably with actual intrinsics outside the template.

The list you provided for the categories of things which could/should be template parameters is quite similar to the list that was in my tutorial.   (I don’t recall what list was in Vipul’s.)  I did not draw a distinction between operators and procedures, but we generally assume that any type-bound procedure can in should be supported.  (Use cases do suggest that binary operators are by the far the most common case in practice.)

With regard to your last statement about strong restrictions:  our definition of “strong” in this context is that there will be constraints in the language specification such that (a) a template that does not provide a full set will not be standard conforming and (b) that the processor will be required to diagnose missing restrictions.       Of course, I have no idea yet on how that would look in bnf, but it does not sound too onerous in the grand scheme of things.

Cheers,

Tom

PS  Would you be interested in attending the bi-weekly generics subgroup meetings on occasion.    They are generally early afternoon (US East coast) time.

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of William Clodius via J3 <j3 at mailman.j3-fortran.org>
Reply-To: General J3 interest list <j3 at mailman.j3-fortran.org>
Date: Wednesday, March 3, 2021 at 6:59 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: William Clodius <w.clodius at icloud.com>
Subject: Re: [J3] [EXTERNAL] Re: Slides available for your preview - Part 2 of the Generics Tutorial today at the J3 plenary

A few comments on the topic of the paper.

Generics/templates in a language are generally intended to provide two different, but related, capabilities: generic containers, and generic algorithms. See for example the C++ standard template library, https://en.wikipedia.org/wiki/Standard_Template_Library. In all languages they are implemented as abstract syntax tree transformations. The containers and algorithms differ in that a container must maintain consistency between the container’s structure and the procedures that operate on it, while an algorithm is typically represented by a single procedure and need not be consistent with anything else.

To maintain consistency between structures and procedures, the generic entity providing the container must encapsulate both the structure and procedures. For C++ and related object oriented languages, the encapsulating entity is normally a class, but for Ada it is the package, and for some other languages it is a structure similar to a package. Fortran currently does not have any entity similar to a class, but its module is very similar to an Ada package. Fortran could add another encapsulating entity similar to a class, but that would further complicate an already complicated language, so I would prefer generic/templated module if generic containers are desired.

In principle, the entity used to package structures and procedures for generic/templated containers can be used to encapsulate single procedures, but the result tends to be syntactically awkward. As a result the languages providing generics/templates, and that includes both C++ and Ada, generally provide generic/templated procedures as separate entities, with a syntax that is related to that for the generic/templated encapsulating structure. If generic algorithms are considered to be important, I believe Fortran should provide generic/templated functions and subroutines, This does mean that a language providing generic/templated containers and algorithms will typically be more complicated than one providing only containers or only algorithms.

The fact that generics/templates rely on syntactic transformation has negative implications for a language as syntactically complicated as Fortran. Type declaration syntax can differ between non polymorphic (TYPE(…)), and polymorphic (CLASS(…)) types. Procedure useage of a procedure can vary depending on whether it is non-type bound or type bound. Entity usage can differ depending on whether it has a LEN type parameter or not. For example hash tables for arrays will be rather different from this for character strings. Rank and size are not part of an object’s type. Some intrinsic procedures have syntax that is impossible for user defined procedures. I suspect others can think of additional syntactic complications. The generic would normally provide different specializations for each syntax supported.

The variety of useful generic/template parameters is larger than this paper suggests. For me they include:

1. Types (for almost any application)

2. Rank or shape (for almost any location where the type is useful)

3. Procedures (for container reduction and mapping operations, sorting and sifting)

4. Operators (syntactic sugar for procedures that are unnamed, comparison operators for sorting, red black trees, etc., identity operator for many containers, concatenation for container construction)

5. Integers for sized containers (bit strings, vectors, arrays, and matrices) or selection of rank based specializations.

6. Logical flags for the selection of simple specializations.

It is easy to require support for strong restrictions, I believe Ada’s syntax provides that, but it is difficult to make it an enforced requirement that a processor use that support to enforce strong restrictions.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210308/f2b2ac97/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/20210308/f2b2ac97/attachment-0001.bin>