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

Thu Mar 4 13:20:41 UTC 2021

William,

Thank you for summarizing the situation in such a clear manner.       I hope to add a few comment when I finish catching up on other work after the J3 meeting.

Cheers,

Tom 

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/20210304/c97958c5/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/20210304/c97958c5/attachment-0001.bin>