[J3] Fwd: [EXTERNAL] Re: Re: Slides available for your preview - Part 2 of the Generics Tutorial today at the J3 plenary
Clune, Thomas L. (GSFC-6101)
thomas.l.clune at nasa.gov
Wed Mar 10 13:36:17 UTC 2021
Bill,
I suspect that the driver for templates is not coming from newbies as much as some other features might. Of course we do want to make templates as simple as possible, but no simpler. Like OO, templates are a powerful means to reduce complexity in large software applications. The local complexity in the template itself is offset by the reduced complexity (and duplication) in the client layers. YMMV.
Regarding not having heard Fortran criticized for lacking "generics": Um, it was one of the 2 top priority items from the survey and from WG5. We may debate the word "criticize" but the lack has certainly been lamented by many, including myself. I'm esp. surprised that Cray (sorry HPE) has not seen such requests, as the C++ performance community is heavily shifting from OO to templates as they (potentially) offer superior run-time performance. (link/compile time polymorphism vs run-time polymorphism).
Cheers,
- Tom
On 3/9/21, 5:25 PM, "J3 on behalf of Bill Long via J3" <j3-bounces at mailman.j3-fortran.org on behalf of j3 at mailman.j3-fortran.org> wrote:
Does seem unnecessarily complicated. We have to keep in mind that designing something that people want to use is a high priority. And keep in mind that the newbies we will want to use this stuff will have learned C++ in school. Simple procedure templates that are compiled (and likely inlined) at instantiation time.
I’ve never heard Fortran criticized for lacking “generics”, but have often heard that the critical thing (in the minds of C++ programmers) missing in Fortran is templates.
Cheers,
Bill
> On Mar 9, 2021, at 3:35 PM, William Clodius via J3 <j3 at mailman.j3-fortran.org> wrote:
>
> I accidentally sent this just to Tom Clune when I meant to send it to the general J3 interest list.
>
>> Begin forwarded message:
>>
>> From: William Clodius <w.clodius at icloud.com>
>> Subject: Re: [J3] [EXTERNAL] Re: Re: Slides available for your preview - Part 2 of the Generics Tutorial today at the J3 plenary
>> Date: March 9, 2021 at 2:29:35 PM MST
>> To: "Clune, Thomas L. (GSFC-6101)" <thomas.l.clune at nasa.gov>
>>
>>
>>
>>> On Mar 9, 2021, at 11:15 AM, Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov> wrote:
>>>
>>> Hi Bill,
>>>
>>> (Apologies – I only now noticed how you sign your name. Somewhere I thought I saw you went by William.)
>>
>> I go by either depending on my or your whim.
>>
>>>
>>> Tom:
>>>
>>> I would argue that the template parameters at the module template level is not necessarily the union of all the template parameters used by the actual templated entities contained therein. If templated modules can contain templated modules or templated procedures then the instantiations of these components can be separately specified relying on their partial instantiation from the instantiation of the enclosing templated module.
>>>
>>> Did you mean “…can contain templated _derived types_ or …”? Otherwise, I’m not sure what you meant above by “containe templated modules”. (Introducing “inner modules” seems one solution to the specific matter under discussion, but that did not seem to be where you were headed.)
>>
>> I mean templated inner modules. Van Snyder’s 04-383r1.pdf, on generic modules has a brief discussion of them. I consider them less intuitive than templated procedures in a module template, but templated inner modules would introduce less new syntax.
>>
>>>
>>> Presuming I’ve understood correctly: I am certainly not at all opposed to having template parameters at the module level. I am merely hoping that they are not only at the module level. And then, if types and procedures can have independent template parameters, the value of parameters at the module level may be minimal. However, the lesson of PDT’s still seems relevant. How do we tie the parameters for a derived type template to the type-bound procedures that the language treats as independent entities on their own right? I can easily imagine mechanisms, but have no idea if any are palatable. Suggestions welcome.
>>
>> For a very abbreviated example using C++ inspired syntax and a templated procedure contained in a templated module. (A templated inner module, would have simila, but slightly wordier syntax.)
>>
>> module <t_t>container_m
>> type :: t_t
>> requirements
>> …
>> end requirements
>> …
>> type container_t
>> type(t_t) …:: element
>> …
>> end type container_t
>> ...
>> contains
>> …
>> pure subroutine add_element( container, a_t )
>> type(container_t), intent(inout) :: container
>> type(t_t), intent(in) :: a_t
>> …
>> end subroutine add_element
>> ...
>> pure subroutine get_next( container, a_t, flag )
>> type(container_t), intent(inout) :: container
>> type(t_t), intent(out) :: a_t
>> logical, intent(out) :: flag ! if false a_t is undefined
>> …
>> end subroutine get_next
>> …
>> pure subroutine < s, t_to_s >map( c, d )
>> type :: s_t
>> procedure :: t_to_s
>> requirements
>> …
>> interface
>> pure function t_to_s( a_t )
>> type(s_t) :: t_to_s
>> type(t_t), intent(in) :: a_t
>> end function t_to_s
>> end interface
>> end requirements
>> use <s>container_m, container_s => container_t ! to be useful assumes the compiler can coalesce duplicate instantiations
>> type(container_t), intent(in) :: c
>> type(container_s), intent(out) :: d
>> …
>> type(t_t) :: a
>> type(s_t) :: b
>> logical :: flag
>> do
>> call get_next( c, a, flag )
>> if ( flag ) then
>> call add_element( d, t_to_s( a ) )
>> else
>> exit
>> end if
>> end do
>> end subroutine map
>> …
>> end module container_m
>>
>> program example
>> …
>> use <u_t>container_m, container_u=>container_t, umap=> map
>> use <v_t>container_m, container_v=>container_t
>> …
>> type(u_t) :: u
>> type(v_t) :: v
>> ...
>> call add_element(container_u, u)
>> …
>> call <v_t, u_to_v>map( container_u, container_v )
>> …
>> end program example
>>
>> As expected significantly wordier than the C++ equivalent. The recursive definition of map on a different instantiation of container_m, is, I believe, implementable, but will require care in the implementation.
>>
>>>
>>> There is no reason that a templated module should be any less flexible than a templated class in C++. However for compatibility with the existing language the same functionality will be wordier than in C++.
>>>
>>> I’m good with that. “Wordier” is possibly a significant understatement, but such is life.
>>>
>>> So far your examples have naturally focussed on simple cases, which of course have been templated algorithms, that don’t necessarily benefit from templated modules and hence don’t provide analyses of the features of templated modules. To examine the features of templated modules it is best to examine a couple of templated containers. Note that my additions to https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fj3-fortran%2Fgenerics%2Fblob%2Fmain%2FUse_cases_and_requirements.md&data=04%7C01%7Cthomas.l.clune%40nasa.gov%7Cb09aa3d6db3a46d0bb0f08d8e34a3429%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637509255186918590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=P4k6iaLnV0q9ioVv1cRe%2FAX4zSOuSI8kT%2BXglZx8jkc%3D&reserved=0 included some at least partial examples of containers.
>>>
>>> I agree that containers bring the issue forward in a way that procedures do not. And we have very much been looking at containers, but not from this perspective. The focus on how to express “restrictions” avoided discussions about how type-bound procedures would be associated with the template parameters of the containing derived type. This thread has now brought that issue to the fore, and presumably will be a major topic of discussion in one of the next two generics meetings. (First priority is probably just an assessment of the J3 reaction to the tutorials, of which this thread is just one element.)
>>>
>>> Cheers,
>>>
>>> • Tom
>>>
>>> Sincerely,
>>>
>>> Bill
>>>
>>>
>>>> On Mar 9, 2021, at 7:02 AM, Clune, Thomas L. (GSFC-6101) via J3 <j3 at mailman.j3-fortran.org> wrote:
>>>>
>>>> Anton,
>>>>
>>>> It is not that parameterized modules cannot address the use cases. The problem is simply that the list of template parameters at that level is the union of all template parameters used by the actual templated entities contained therein. Magne says that experience in other languages as that well-designed templates will encourage extensions and the module-level approach will lead to long lists that are more difficult to use.
>>>> Not a catastrophe. But not ideal either.
>>>>
>>>> If I understand correctly, you are endorsing parameterized modules against other solutions. None of which have yet been proposed. The examples in the tutorials were not even intended to address this particular issue. Rather they focused on small motivating examples for "restrictions" and potential ways to deal with the irregularities in existing Fortran syntax. Granted, the examples put the template parameters on the types and the procedures, but that was not the intent per-se. (I'll also grant that it does reveal a bias on the part of the presenters.) If nothing else, that makes the examples smaller by a few lines each which is useful in PPT.
>>>>
>>>> Cheers,
>>>>
>>>> - Tom
>>>>
>>>> <snip>
>>
>
Bill Long longb at hpe.com
Engineer/Master , Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9143
Hewlett Packard Enterprise/ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
More information about the J3
mailing list