generics

generics copied to clipboard

Tom et al:

About two years ago I submitted a paper to J3 that became J3/18-240r1.txt. Since then I have significantly revised and extended that paper. The examples (a generic swap subroutine and modules for linked lists, bitsets, and hash tables) might be filled out to serve as use cases. Would you be interested in my placing a copy of the revised paper in this repository?

Your timing is good. I'm trying very hard to block off some time to focus on generics in preparation for the October meeting. Also, I feel a bit bad that I apparently never saw 18-240r1, or at least no longer recall it. (I sometimes just make it to the meeting and work on the papers as directed by the subgroup chair - most likely what happened in this case. Apologies.) The good news is that several of your use cases in 18-240 did appear in other use case papers that were discussed.

I certainly encourage you to submit additional papers along these lines. For now I would focus less on example syntax unless you think it is essential to understanding and instead to focus on use cases. Ideally there would be a different paper for each use case so that we can get some traceability when starting to write the requirements paper(s).

My possibly naive hope is to have a collection of larger real-world use cases that pass in plenary as the baseline driver for generics. From these we would derive a suite of more narrowly focused "micro" use cases. E.g., containers are a great use case, but there are numerous semi-independent aspects: types as parameters, co-routines, LHS accessors, etc. Some might pass and some might not. With this approach, I hope to short-circuit some of the debates when we move on to formal requirements. If each formal requirement can explicitly cite one or more micro use cases (and thus also full use cases) that have already passed in earlier papers, there should be few objections other than to improve clarity. (People can of course be inconsistent, but I can hope.)

Note: I also now need to figure out if the work should move over to the main Fortran GitHub repo started by Ondrej, or to keep it here.

I should add that I am pretty much on the same page as your paper regarding program units and parameters. I need to give more though to the submodule aspect though.

I gave up on the submodule concept, as too different from the normal semantics of submodules. For instantiation of generic modules I now suggest something along the lines of a create statement to be used anywhere in the specification part that the actual parameters have been previously defined:

create-module-stmt is CREATE MODULE [ module-name => ] generic-name & ( actual-param-spec-list ) [ , rename-list ] or CREATE MODULE [ module-name => ] generic-name & ( actual-param-spec-list ) ONLY : [ only-list ]

actual-param-spec is [ keyword = ] actual-param or [ OPERATOR( defined-operator ) = ] actual-param

actual-param is intrinsic-type-spec or derived-type-spec or expr or variable or procedure-name or proc-component-ref or OPERATOR( defined-operator )

There are a number of constraints the actual parameters must satisfy. The type specifiers will be required to correspond to dummy arguments that are declared to be types. Expresssions and variables to dummy arguments with a type declaration statement. I suspect that at least initially we will want to further restrict actual expressions and "variables" to be constants. Some might want to further restrict them to being integers so they match the specification expression constraints. Procedure and operator actual parameters should be restricted to correspond to dummy parameters with explicit interfaces.

By providing a module-name, those that desire to use the generic with the same instantiation parameters need only refer to that name, rather than instantiating the generic module again. If the standard defined a template library, then it could instantiate the generics for the intrinsic types giving each instantiation a distinct module name, allowing reuse of the library with minimal code bloat.

On Sep 9, 2020, at 11:22 AM, Tom Clune [email protected] wrote:

I should add that I am pretty much on the same page as your paper regarding program units and parameters. I need to give more though to the submodule aspect though.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sourceryinstitute/generics/issues/7#issuecomment-689705803, or unsubscribe https://github.com/notifications/unsubscribe-auth/APTQDOTQLTEAF7HG3AXJ5H3SE62UVANCNFSM4RAJCB3A.

FWIW I have already submitted three papers on Ondrej’s website. They have yet to be forwarded to the official J3 website maintained by Steve Lionel. I may prompt Ondrej in a couple of days.

On Sep 9, 2020, at 11:17 AM, Tom Clune [email protected] wrote:

Your timing is good. I'm trying very hard to block off some time to focus on generics in preparation for the October meeting. Also, I feel a bit bad that I apparently never saw 18-240r1, or at least no longer recall it. (I sometimes just make it to the meeting and work on the papers as directed by the subgroup chair - most likely what happened in this case. Apologies.) The good news is that several of your use cases in 18-240 did appear in other use case papers that were discussed.

I certainly encourage you to submit additional papers along these lines. For now I would focus less on example syntax unless you think it is essential to understanding and instead to focus on use cases. Ideally there would be a different paper for each use case so that we can get some traceability when starting to write the requirements paper(s).

My possibly naive hope is to have a collection of larger real-world use cases that pass in plenary as the baseline driver for generics. From these we would derive a suite of more narrowly focused "micro" use cases. E.g., containers are a great use case, but there are numerous semi-independent aspects: types as parameters, co-routines, LHS accessors, etc. Some might pass and some might not. With this approach, I hope to short-circuit some of the debates when we move on to formal requirements. If each formal requirement can explicitly cite one or more micro use cases (and thus also full use cases) that have already passed in earlier papers, there should be few objections other than to improve clarity. (People can of course be inconsistent, but I can hope.)

Note: I also now need to figure out if the work should move over to the main Fortran GitHub repo started by Ondrej, or to keep it here.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sourceryinstitute/generics/issues/7#issuecomment-689703356, or unsubscribe https://github.com/notifications/unsubscribe-auth/APTQDOXQEG6U4KMNGCCOARLSE62BVANCNFSM4RAJCB3A.

Tom have you figured out if the work should move over to the main Fortran GitHub repo started by Ondrej, or to keep it here? FWIW I now have two papers on use cases for hash tables and bitsets.

FWIW I now have a couple more papers on use cases for bitsets, red-black trees, and sorting.

FWIW I have edited the papers on use cases for red-black trees and hash table to emphasize their use as ordered maps and unordered maps, respectively.

@wclodius2 Do you have the energy to attempt to fuse those into the draft paper in the main directory? You understandably may want to wait just a bit, as the structure is still a bit vague - basically I pasted with a bit of tidying one of my containers papers.

@tclune I have added what I have, which I expect will be more than what you expected.

1. I have added two sections on "Generic Algorithms" and "Generic Containers";
2. I have greatly expanded the number of generic algorithms discussed;
3. I have added Lists to the discussion of generic containers and greatly modified the discussion of Vectors, Maps, and Sets;
4. I have attempted to derive requirements for each generic algorithm and container;
5. I have made other, more minor, changes.

Do with the changes as you will.

FWIW I an disturbed at the implications of the large number of variations in Fortran's "type" syntax: polymorphic (CLASS) versus non-polymorphic (TYPE), type-bound procedures versus non-type bound, types with a LEN or KIND parameter versus unparameterized types. They seem to require either a large number of specializations, or the user to use wrapper types. I am also concerned at how useful iterators are for generic algorithms. It will be difficult to come up with a simple syntax for iterators since Fortran doesn't have exception handling. It will also be difficult to come up with an iterator syntax for arrays.

FWIW I have added an introduction to my edits.