[J3] [EXTERNAL] 21-144r2

Clune, Thomas L. (GSFC-6101) thomas.l.clune at nasa.gov
Tue Jun 22 13:23:07 UTC 2021


Hi Anton,

Actually, the paper ended up well below where my original ambitions had aimed, but hopefully at least gives us enough to move forward with a reasonable requirements paper.  (Possibly with significant revision.)

The intent of the straw votes is not to tie the hands of the subgroup (or  J3/WG5) in the event that solutions become overly complex or undesirable.      Rather, the question is about priorities - is this something that a reasonable person would _want_ the generics facility to enable.    And, as Van noted in his reply, there have been enough specific requests for a SWAP feature that presumably this first straw vote is an easy sell. 

I share some of your concerns about the corner cases, and some of  the later straw votes examine some "annoying" issues in a more isolated fashion.   Indeed, probably half of subgroup time over the last 6 months has been consumed with how general things should be and/or how to best hide some of the complexity from the end user.

Length-type parameters for PDTs are one of those "annoying" issues.   Strings are only a special case, albeit a very common/important special case.    In the case of SWAP, the new TYPEOF feature helps a great deal, but does not solve all of the related issues.    One path would be to add an additional template parameter that controls whether the arguments are allocatable (or pointer).   Another could be to provide a mechanism to encapsulate type parameters and attributes within the template parameter "T".      I think that something along the lines of the latter is highly desirable for handling kind type parameters.   If we were only worried about intrinsic types, then a template could simply add one (or maybe a few) integer template parameters for controlling the kinds of the procedure arguments, but that would not work for arbitrary PDTs.  (Or alternatively, we could decide that generics explicitly does not provide any special support for PDTs, as generics will to some degree supersede such functionality.)

For the CONTAINERS straw votes - I agree that the question is rather vague.      Partly this was due to the rush to put the paper out before I left for vacation, but it also reflects that I could not come up with a better approach.    As I mentioned above, the real goal is to get a sense from J3 whether subgroup should invest effort in making these use cases friendly to developers/end-users.    Mostly this is a defense against atrocious/painful approaches that technically work.   (E.g., using INCLUDE).      Perhaps further discussion on Wednesday will reveal a better way to capture committee sentiments.   Even if the paper does not pass in this iteration, subgroup will hopefully have strong enough direction on important elements that we can refine before the next meeting and have a solid requirements paper to debate.

- Tom 


On 6/21/21, 8:35 PM, "Shterenlikht, Anton" <anton.shterenlikht at hpe.com> wrote:

    Hello Tom & Generics Group

    RE: 21-144r2

    YOu guys have done amazing work, and I thank you
    for the ambition and attention to detail.

    However...

    The paper has become too general to make judgements.

    Few examples:

    *quote*
    ALG-1: Should the generics facility enable developers to define a
           scalar SWAP template that will apply to any type that supports
           assigment?  (YES, NO, UNDECIDED, ABSTAIN)
    *end quote*

    Sounds great - but will such facility be very complicated
    to accommodate "any type that supports assignment"?
    Depending on the complexity, I'd vote yes or no.
    Should an allocatable character scalar variable 
    always be swappable with fixed length
    character scalar variable?
    With truncation or padding of the fixed length var?
    I worry that unexpected corner cases under "any type..."
    will be discovered later, which will push the complexity even further.


    MOst of the CONTAINERS-* questions are too vague to make a decision:

    "convenient", "easy-to-use", "easily", "well-written",
    "convenient-to-use"

    (BTW, a typo:
    CONTAINERS-6: Should Fortran's generics facilities enable users of
                  relevant containers to indepndently
                                              ^                  )


    Thank you

    Anton



More information about the J3 mailing list