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

Thu Jul 13 08:28:19 EDT 2017

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

> 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