(j3.2006) (SC22WG5.5914) Preview of possible feature survey

[Van Snyder]

On Thu, 2017-07-13 at 21:07 +0000, Bill Long wrote:
> > On Jul 13, 2017, at 7:28 AM, Clune, Thomas L. (GSFC-6101)
> <thomas.l.clune at nasa.gov> wrote:
> > 
> > I?d like to follow up on a narrow sliver of this debate.     I
> certainly agree with Van that there is a big difference between
> relegating a feature due to resource constraints as opposed to
> rejecting an idea on its own merits.
> > 
> > But I would argue that even the latter case could (on rare
> occassions) require renewed attention by the committee.   Opinions
> about the value/impact of features evolve for multiple reasons.
> First, the existence of other new features might provide some
> synergism with a proposed feature.   Second, downsides of a feature
> might seem less severe after further thought/design.   And finally, as
> software complexity in major models continues to grow, features that
> help to reduce/manage said complexity may become more desirable.  (Ala
> any solution to generic programming.)
> 
> Some features might be easier to add to Fortran now, if they can build
> on changes in recent revisions.  That certainly is worth considering. 

Some things that we did wouldn't have been done if the
originally-requested more general feature had been done.  For example,
the kludge of disassociated pointers corresponding to optional
nonpointer dummy arguments not being present wouldn't have been done if
we'd done conditional expressions, spelt in C as "a?b:c", with the
variation that something like "a?b" could appear only as an actual
argument corresponding to an optional dummy argument, and the dummy
argument is absent if "a" is false.

> Cheers,
> Bill
> 
> 
> > 
> > 
> > 
> >> On Jul 12, 2017, at 7:39 PM, Van Snyder <Van.Snyder at jpl.nasa.gov>
> wrote:
> >> 
> >> On Wed, 2017-07-12 at 22:25 +0000, Bill Long wrote:
> >>> Five is negotiable. Maybe 8, or even 10.  But 50 is obviously
> unfair
> >>> to the committee, especially if they are ones repeatedly rejected
> in
> >>> the past.  Such abuse would be unacceptable. 
> >> 
> >> There is a difference between "That's a terrible idea that we'll
> never
> >> consider" and "That's a good idea but there's more important stuff
> to do
> >> right now."  I don't propose to bring back proposals that had
> negative
> >> opinions recorded in the 2004-05 spreadsheets.  For example, using
> >> function result types as an additional criterion for generic
> resolution
> >> (rejected 2-10) won't be coming back, unless we do enumerated
> types, for
> >> which it's crucial to make them work smoothly.  New types, not type
> >> aliases (accepted for further consideration 10-1 in 05-143r3) will
> be
> >> returning.  Type alias, which displaced new types, is an enormously
> >> inferior idea that fortunately was abandoned to trim the work plan.
> >> 
> >> Proposals for 2015 that were vetoed in subgroup at Delft and Las
> Vegas
> >> but never discussed in plenary were not rejected (being discussed
> by
> >> three people who voted 2-1 not to put the proposal forward isn't
> >> rejection in my book), and some of those might be coming back.
> >> 
> >>> And certainly none for parameterized modules, which, as you note,
> we
> >>> have already rejected.
> >> 
> >> Parameterized modules were not rejected.  They had the third
> highest
> >> priority in 05-143r3, after coarrays and rewriting attribute
> >> requirements.  They were above DO CONCURRENT and CONTIGUOUS.  There
> were
> >> only nine "A" priority items in 05-143r3, and the other eight were
> >> implemented.  There were none with a higher "hate dislike like
> love"
> >> score (0 0 7 4), and the only one with the same score was to get a
> >> logical I/O unit number (became NEWUNIT in OPEN).
> >> 
> >> Parameterized modules were displaced by macros, which were thought
> to be
> >> simpler to describe and implement, to trim the work plan.  Macros
> were
> >> then abandoned (but not really rejected either) to trim the work
> plan.
> >> 
> >> People have been talking about generic programming in Fortran for
> years.
> >> Why isn't it OK to revisit the question of how we ought to provide
> >> support?  There was offline discussion precisely of parameterized
> >> modules in Garching, where we explicitly decided that online
> discussion
> >> of new features was premature until we had developed a procedure to
> >> process them.  One of the propositions in the draft plan for
> gathering
> >> requirements was to ask C++ users why they fled from Fortran.  That
> >> question has been asked and answered numerous times:  To get
> templates.
> >> Users did not abandon Fortran in favor of C++ to get CPP, and the
> reason
> >> "to get OOP" doesn't hold water any more.
> >> 
> >> If we had done parameterized modules in 1990 (there was already
> seven
> >> years' experience with them in Ada by then, and no experience in
> any
> >> language with PDT), we probably would not have done parameterized
> >> derived types, and there would not now be an integration gap
> between PDT
> >> and type-bound procedures.  Maybe if we do parameterized modules we
> can
> >> print all the PDT stuff in small type.
> >> 
> >> Some things that were "rejected" in 04-302 we did anyway.  For
> example,
> >> we did an entire TS on further interoperability
> (hate-dislike-like-love
> >> score was 1 11 0 0).
> >> 
> >> 
> >> _______________________________________________
> >> 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
> 
> Bill Long
> longb at cray.com
> Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
> Bioinformatics Software Development                      fax:
> 651-605-9143
> Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3