(j3.2006) (SC22WG5.5869) [ukfortran] N2126

[Keith Bierman]

I don't recall the committee being against use cases as such.

The tension has always been between what "users" are perceived to want and
what implementors are able to (practically, subject to
Management/funding/etc.) deliver.

I believe Steve made an excellent point about the pragmatics ... few
sensible organizations are willing to commit to using features which aren't
supported by multiple compilers. Few vendors are currently fully funding
Fortran compiler development (and code quality/performance tends to have a
much higher perception as being critical customer satisfiers to most
Management chains).

Obviously there's a feedback loop; when there are few perceived paying
customers, there tends to be less funding, which may well drive customers
away.

Sorry, I don't have any magic wand or beans to make life easier ;<

Keith Bierman
khbkhb at gmail.com
303 997 2749

On Mon, Jun 5, 2017 at 2:19 PM, Clune, Thomas L. (GSFC-6101) <
thomas.l.clune at nasa.gov> wrote:

> Van,
>
> I see this as a perfect explanation of why use cases _are_ very
> important.   (And possibly a demonstration that decisions made by
> committees should not be expected to be perfect in every instance. What a
> surprise!)
>
> I have several different use cases  that would be satisfied by some type
> of generic programming feature.      But not all generic programming
> features would satisfy all of my use cases.      With the use cases in
> hand, the committee can make trade-offs between complexity if
> implementation and the perceived importance of the various use cases.
> For example, one of my big use cases is for ?containers?  (ala C++ STL).
>    If this were the only use case, then one possible solution would be to
> introduce new container types: Vector, Set, Map, ?     This would hardly
> count as a general-purpose approach to generic programming, but would
> nonetheless provide some very useful functionality.    Alternatively, some
> sort of templating mechanism would be more general purpose, but would
> probably not easily handle some of the edge cases I have and certainly
> would require more effort on the part of the end user to implement the
> logic for robust containers.
>
> Note - I?m not intending this as a platform to argue for or against
> generic programming or a particular choice of feature for such.  This is
> just meant to illustrate the value of use cases.
>
> Cheers,
>
> - Tom
>
>
>
> > On Jun 5, 2017, at 3:16 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> >
> > On Mon, 2017-06-05 at 12:45 +0000, Clune, Thomas L. (GSFC-6101) wrote:
> >>> widely available, and widely used,
> >>> in other high level languages - is that not a use case?
> >>
> >> Not an argument that generally gets much sympathy in this committee.
> >> Just work it backwards - why were those features widely used in the
> >> other languages?
> >
> > People aren't rushing from Fortran to C++ to get the C preprocessor.
> > They want templates (which were called generic packages in Ada in 1983).
> > We briefly considered parameterized modules, then macros, then
> > essentially no support for generic programming.
> >
> > Both Ada and C++ supported generic programming from their origination,
> > so it's not a new untried mystery.
> >
> > If we had had parameterized modules, it is unlikely we would have done
> > parameterized derived types -- at least not with kind parameters.  And
> > we wouldn't have ended up with the disconnect between parameterized
> > types and type-bound procedures that Richard Maine warned about twenty
> > years ago.
> >
> >
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170605/b44480e0/attachment-0001.html