On Mar 24, 2016, at 7:35 AM, Tom Clune <[log in to unmask]> wrote:
>
>> On Mar 23, 2016, at 10:24 PM, Vipul Parekh <[log in to unmask]> wrote:
>>
>> Thank you for your response and your prior proposal effort. It received 4 "like"s, 1 "love" but 6 dislikes (at least no hate!), if I understood correctly. Considering the year of the proposal, you might have been way ahead of where Fortranners were that stage of language evolution and perhaps there was post-Fortran 2003 fatigue too! I wonder if there might be better reception now, given better understanding and appreciation of modern programming idioms and paradigm, particularly with OO, among many in the Fortran community Of course, from what I gather, the committee won't be considering any new proposals until the current revision (2015?) is all done.
>
> Correct. And then the challenge will be to narrow priorities. As much as we on the applications side want many new features, it does us no good if we dump too much on the vendors. So the goal is to also estimate the implementation difficulty as we propose/prioritize features for 2020.
Right. And, it is perhaps mentioning that any change that affects the typing system (apart from trivial syntax enhancements like type(integer)) can involve non-trivial implementation issues.
Cheers,
Bill
> The president of the committee has indicated that the process will rely heavily on _use cases_. I.e. the proposer will need to explain likely/relevant scenarios for which the new feature significantly improves the implementation.
>
>>
>> It's reassuring to read, '"There would be no conflicts with the standard to introduce enumeration types. If they were introduced, they would not invalidate any program that conforms to current standards."
>>
>> Your point, "My later thoughts on the topic is that enumeration types ought to be extensible," makes sense.
>>
>> If you were to develop again your proposal now, to what extent you think it will support the couple of examples I show in my first e-mail?
>
> As I’m relatively new to the committee, I’ll await Van’s response and others to this.
>
> Cheers,
>
> - Tom
>
>>
>> Regards,
>> Vipul
>>
>> On Wed, Mar 23, 2016 at 7:32 PM, Van Snyder <[log in to unmask]> wrote:
>> I proposed this in 2004. See paper http://j3-fortran.org/doc/year/04/04-139r1.ps. It met with an unwelcome reception, as can be seen in http://j3-fortran.org/doc/year/04/04-302.xls. There would be no conflicts with the standard to introduce enumeration types. If they were introduced, they would not invalidate any program that conforms to current standards. My later thoughts on the topic is that enumeration types ought to be extensible.
>>
>> In Ada, function results participate in generic resolution, and enumerators are considered to be zero-argument functions. It is therefore possible to have enumerators of different types with the same names. Proposals to include function result types (and kinds, and ranks) in generic resolution have also met with unwelcome receptions.
>>
>> On Wed, 2016-03-23 at 16:52 -0400, Vipul Parekh wrote:
>>> Hi,
>>>
>>>
>>> I posted this on comp.lang.fortran, but not sure how many of you read that newsgroup. I apologize for any duplication of effort.
>>>
>>>
>>> Regards,
>>> Vipul Parekh
>>>
>>>
>>> ---------------------------------------------------
>>> From a language and compiler development point-of-view, putting aside any time/resource constraints, are there any fundamental issues with including an improved "enum" functionality in Fortran?
>>>
>>> That is, from the language aspects of Fortran syntax, semantics, and taxonomy, is there an intrinsic problem that might preclude any enhancements beyond the facility for enum introduced in Fortran starting with the 2003 revision toward standard interoperability with C?
>>>
>>> I would greatly appreciate any knowledgeable feedback on above.
>>>
>>> I'm greatly interested in better support for "enum" types in Fortran. I would like to adopt many of the so-called "good coding practices" involving enum that are used regularly by my peer group within industry in languages such as C++, Python, Java, and Microsoft .NET. Listed below are a couple of examples in C++ that capture most of what I would like to do.
>>>
>>> 1. Intrinsic support for an integral type of "enum" which provides facilities toward improved code readability and some form of type safety. You will see in C++, I can do the following for working with days in a week:
>>>
>>> --- begin code ---
>>> #include <iostream>
>>> using namespace std;
>>>
>>> enum Days { Sunday = 0, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday };
>>>
>>> // main example
>>> int main(void)
>>> {
>>>
>>> Days Today;
>>> Today = Days::Wednesday; // Ok, and code reads much better too
>>> //Today = 2; // Error, cannot convert from int to Days
>>>
>>> switch ( Today )
>>> {
>>> case Days::Wednesday:
>>> cout << "It's a Wednesday" << endl;
>>> break;
>>> case Days::Saturday:
>>> case Days::Sunday:
>>> cout << "It's a Weekend!" << endl;
>>> break;
>>> default: cout << "It's some other day." << endl;
>>> }
>>>
>>> return 0;
>>>
>>> }
>>> --- end code ---
>>>
>>> It will be nice if I can do in Fortran:
>>> --- begin pseudo code ---
>>> module m
>>> implicit none
>>> private
>>> enum, public :: Days !.. Not supported at present
>>> enumerator :: Sunday = 0
>>> enumerator :: Monday
>>> enumerator :: Tuesday
>>> enumerator :: Wednesday
>>> enumerator :: Thursday
>>> enumerator :: Friday
>>> enumerator :: Saturday
>>> end enum
>>> end module m
>>> program p
>>> use m, only : Days
>>> type(Days) :: Today
>>> Today = Days%Tuesday
>>> !Today = 2 !! Should not be allowed, no direct integer assignment to enum type
>>> select case ( Today )
>>> case ( Days%Tuesday )
>>> print *, "It's a Tuesday!"
>>> case ( Days%Saturday, Days%Sunday )
>>> print *, "It's a weekend!"
>>> case default
>>> print *, "It's some other day!"
>>> end select
>>> stop
>>> end program p
>>> --- end pseudo code ---
>>>
>>> Does anyone of you think facilities along the above lines are simply inconsistent with the language? If so, why? Note I'm not wedded to my invented syntax in the above pseudo snippet; it was just for illustration purposes. My interest is really in being to program in "modern" Fortran the kind of coding idioms involving "enum" that my peers have accepted as more readable and type-safe.
>>>
>>> 2. Better support for use of "enum" with object-oriented (OO) design. I would like to build on the above point and extend it to components for derived types so it can help me further in OO concepts involving class design, data packaging, information hiding, and so forth. Consider an example in C++ again where one can write a class for day of a week as follows:
>>>
>>> --- begin code snippet ---
>>> #include <iostream>
>>> using namespace std;
>>>
>>> class Day
>>> {
>>> public:
>>>
>>> enum Days { Sunday = 0, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, InvalidDay };
>>>
>>> // Constructors
>>> Day(void);
>>> Day(Days d);
>>>
>>> // Overloaded assignment operator
>>> Day& operator = (Days d);
>>>
>>> // Overloaded comparison operator
>>> bool operator== (const Days d) const;
>>>
>>> // Accessor function
>>> Days getDay(void) const;
>>>
>>> private:
>>>
>>> // Data member
>>> Days m_day;
>>> };
>>>
>>> Day::Days Day::getDay(void) const
>>> {
>>> return m_day;
>>> }
>>>
>>> // Constructors
>>> Day::Day(void) : m_day(Sunday) {}
>>>
>>> Day::Day(Days _d) : m_day(_d) {}
>>>
>>> // Assignment operator
>>> Day& Day::operator= (Days _d)
>>> {
>>> m_day = _d;
>>> return *this;
>>> }
>>>
>>> // Comparison operator
>>> bool Day::operator== (const Days _d) const
>>> {
>>> return (m_day == _d);
>>> }
>>>
>>> // main example
>>> int main(void)
>>> {
>>>
>>> Day Today;
>>>
>>> Today = Day::Tuesday; // Ok, and code reads much better too
>>> //Today = 2; // Error, cannot convert from int to Days
>>>
>>> switch ( Today.getDay() )
>>> {
>>> case Day::Tuesday:
>>> cout << "It's a Tuesday" << endl;
>>> break;
>>> case Day::Saturday:
>>> case Day::Sunday:
>>> cout << "It's a Weekend!" << endl;
>>> break;
>>> default: cout << "It's some other day." << endl;
>>> }
>>>
>>> return 0;
>>> }
>>> --- end code snippet ---
>>>
>>> So I would like to be able to do in Fortran,
>>>
>>> --- begin pseudo code snippet ---
>>> module m
>>> implicit none
>>> private
>>> type, public :: Day
>>> private
>>> enum, public :: Days ! Note how enum is "bound" to the type!
>>> enumerator :: Sunday = 0
>>> enumerator :: Monday
>>> enumerator :: Tuesday
>>> enumerator :: Wednesday
>>> enumerator :: Thursday
>>> enumerator :: Friday
>>> enumerator :: Saturday
>>> end enum
>>> type(Days) :: m_day
>>> contains
>>> private
>>> procedure, pass(this) :: assign_day
>>> procedure, pass(this), public :: getDay
>>> generic, public :: assignment(=) => assign_day
>>> end type
>>>
>>> contains
>>> subroutine assign_day( this, SomeDay )
>>> !.. Argument list
>>> class(Day), intent(inout) :: this
>>> type(Days), intent(in) :: SomeDay
>>>
>>> this%m_day = SomeDay
>>>
>>> end function assign_day
>>>
>>> function getDay( this ) result( ThisDay )
>>> !.. Argument list
>>> class(Day), intent(in) :: this
>>> !.. Function result
>>> type(Days) :: ThisDay
>>>
>>> ThisDay = this%m_day
>>>
>>> end function getDay
>>>
>>> end module m
>>>
>>> program p
>>> use m, only : Day !.. Note the compact use statement
>>> type(Day) :: Today
>>> Today = Day%Tuesday
>>> select case ( Today%getDay() )
>>> case ( Day%Tuesday )
>>> print *, "It's a Tuesday!"
>>> case ( Day%Saturday, Day%Sunday )
>>> print *, "It's a weekend!"
>>> case default
>>> print *, "It's some other day!"
>>> end select
>>> stop
>>> end program p
>>> --- end pseudo code snippet ---
>>>
>>> Again, are there any basic language and compiler development constraints that would prevent a future Fortran standard revision (Fortran 20XY beyond the one in progress Fortran 2015) from adopting support along the above lines? Note I am not asking about the time and effort it takes in getting any such change discussed and accepted by the standards committee and then to get it all documented in standard-speak and for compiler writers to get the features implemented.
>>>
>>> Also, note I am not here to debate in general any of the limitations with using enum types in programming (I understand the pros and cons). Nor do I want to know any of the "virtues" of writing so-called simple, concise code with FORTRAN; I've supported many such programs and I know what they entail.
>>>
>>> Instead I have a general interest in understanding better the hurdles that might hinder further evolution of the Fortran language and presently I'm pondering over the enum functionality. Is it mainly time and resource constraints? Or is there more to it than meets the eye?
>>>
>>> Fortran 2003 introduced "ENUM, BIND(C)" keyword to encapsulate enumerators for interoperability with C and Fortran 2008 brought the TYPE statement for intrinsic types. In my simple-minded thinking, I see these as seeds that can grow into better support for enum. Since an "enum" type is a particular packaging of an integral type and the elements to do such packaging appear to be present in Fortran, I wonder if Fortran language can be extended to provide more "syntactic sugar" for coders.
>>>
>>> Thank you for your attention,
>>>
>>
>>
>
> Thomas Clune, Ph. D. <[log in to unmask]>
> Software Infrastructure Team Lead
> Global Modeling and Assimilation Office, Code 610.1
> NASA GSFC
> MS 610.1 B33-C128
> Greenbelt, MD 20771
> 301-286-4635
>
>
>
>
>
>
>
>
>
>
>
>
>
Bill Long [log in to unmask]
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
|
