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

[Bill Long]

> 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. 

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