Tom:
Take a look at 04-139r1.
Van
On Wed, 2016-10-26 at 17:24 +0000, Clune, Thomas L. (GSFC-6101) wrote:
> Hi Vipul,
>
>
> I think there is a compelling case for better ENUMs, but of course
> will defer on where they would be in terms of priorities. And I
> certainly cannot comment on the implementation difficulty - a very
> important factor in the committee’s decision-making process.
>
>
> Presumably _if_ there were an enhanced form of ENUM, then an
> appropriate extension to SELECT CASE would be considered as part of
> the process of integrating the new feature consistently into the
> standard.
>
>
> Cheers,
>
>
> - Tom
>
>
>
>
>
>
>
> > On Oct 26, 2016, at 12:31 PM, Vipul Parekh <[log in to unmask]>
> > wrote:
> >
> > Hello Tom,
> >
> >
> > I appreciate your response greatly, thank you.
> >
> >
> > Re: your suggestion, "you’d need to provide some highly motivating
> > use cases", well I wonder what, if anything, might quality as
> > motivating!? For me, the immediate use case is with trying to roll
> > my own strongly-typed and scoped ENUM facility in my Fortran, along
> > the lines of enhanced enum introduced in C++ starting with 11
> > standard revision -
> > see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf.
> >
> >
> > Re: enumerations, you may be aware of some recent threads at
> > comp.lang.fortran:
> > https://groups.google.com/forum/#!
> > searchin/comp.lang.fortran/FortranFan$20enum%
> > 7Csort:relevance/comp.lang.fortran/iWUgXY0UJ4s/LoPqAJggEAAJ
> >
> > https://groups.google.com/forum/#!
> > searchin/comp.lang.fortran/FortranFan$20enum%
> > 7Csort:relevance/comp.lang.fortran/Kc15pVHxOQg/f6e5pEBzDgAJ
> >
> > https://groups.google.com/forum/#!
> > topic/comp.lang.fortran/W70llWwUBHw
> >
> >
> >
> > So what I have currently is a simple-minded implementation of a
> > parameterized ABSTRACT derived type that has all bindings with the
> > generic interfaces for required operations such as == and /= and
> > UDDTIO, etc. but it also needs a public "val" integer component. So
> > for any particular ENUM that is desired, say Days, there is an
> > extension type for it from the abstract base with one additional
> > type-bound procedure which is a setter method that extends the
> > generic assignment taking the extension type as RHS. Additionally I
> > use the common Fortran 95 trick with a "collection" type whose
> > components are each extension type (as in Sunday, Monday, etc.) and
> > finally I include a "named constant" of said collection. With such
> > design, one can consume the 'enums' with code like so:
> > ..
> > use Day_m, only : Day, Days ! Day is a derived type; Days is a named constant
> > ..
> >
> > type(Day) :: Today
> >
> > Today = Days%Wednesday
> > !Today = 2 ! compiler error; not allowed as intended due to strong typing
> > select case ( Today%val ) !** Would like NOT to access the Val component in this construct
> > case ( Days%Wednesday%val )
> > print *, "Hey, Pay Day!"
> > case ( Days%Friday%val )
> > print *, "TGIF!"
> > case ( Days%Saturday%val, Days%Sunday%val )
> > print *, "It's a weekend!"
> > case default
> > print *, "Bad day in a cube farm :-("
> > end select
> >
> > print *, "Today is ", Today ! UDDTIO in effect; expected output is Today is Wednesday
> > ..
> >
> >
> > Note also the above derived type implementation allows for enum-like
> > facility in procedure arguments, as components of other derived
> > types ('classes'), and so forth.
> >
> >
> > But sure if a future Fortran standard were to include an enhanced
> > ENUM facility (something which I had brought up on this mailing list
> > back in March), my immediate use case disappears but I think the
> > concept of an improved SELECT CASE with certain designs of derived
> > types is still worthy of consideration.
> >
> >
> > Please note I fully realize all of this falls only in the category
> > of "syntactic sugar", so why bring it up all? Because I work in
> > industry and boy, do Fortranners need some helping hand here!
> >
> >
> > Between C++, C# (more like Microsoft .NET), Python, MATLAB, and
> > Excel/VBA, the space for Fortran in industry can soon shrink to
> > nothingness unless Fortran quickly fills some gaps in helping coders
> > write expressive, efficient, and easy-to-maintain code (productivity
> > is very important in industry) while retaining the power of numeric
> > computing such as array handling and now coarrays.
> >
> >
> > I'm immediately drawn to all the 'goodies' that can be made
> > available to Fortranners which can then make Fortran code robust and
> > yet expressive and easy-to-read. I think it's getting very close
> > with 'modern Fortran' syntax. With a few options included in the
> > standard and with improving editors, toolchains and IDEs, the
> > overall experience can be greatly improved. Once this is realized,
> > the managers and purse-string holders can be more readily convinced
> > to reinvest in Fortran for more computing needs in industry. That's
> > my motivation - how is that for a use case?!!
> >
> >
> > Best Regards,
> > Vipul
> >
> >
> >
> >
> >
> > On Tue, Oct 25, 2016 at 9:46 AM, Clune, Thomas L. (GSFC-6101)
> > <[log in to unmask]> wrote:
> > Hi Vipul,
> >
> >
> > I think you’d need to provide some highly motivating use
> > cases. In my experience it is relatively unusual to have
> > derived type PARAMETERs. One of the major reasons for
> > this is that PRIVATE components within a derive type will
> > generally prevent PARAMETERs of that derived type.
> > Also note that the structure is intended to work with CASE(…
> > ) values that are known at _compile_ time. E.g., the
> > standard does not even support the following:
> >
> >
> > INTEGER :: i, j, k
> > SELECT CASE (i)
> > CASE (j)
> > …
> > CASE (k)
> > …
> > END SELECT
> >
> >
> > Other things for you to consider:
> >
> >
> > 1) The standard does not even support SELECT TYPE for REAL
> > and COMPLEX types. I’ve only been on the committee for a
> > short time, but I suspect there has not been much demand for
> > these.
> >
> >
> > 2) The compiler needs to know how to detect which case
> > applies? You apparently ntended your hash to provide that
> > definition, but in that case you can already do what you
> > want. Just use the hash directly:
> >
> >
> > SELECT TYPE (bar%get_hash_code())
> > CASE (COMPILE_TIME_KNOWN_HASH_OF_FOO)
> > …
> > CASE default
> > …
> > END SELECT
> >
> >
> >
> >
> > Of course, you’d need to find a method to know the hash of
> > foo at compile time, which is possibly problematic in
> > practice.
> >
> >
> > Cheers,
> >
> >
> > - Tom
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > On Oct 25, 2016, at 9:00 AM, Vipul Parekh
> > > <[log in to unmask]> wrote:
> > >
> > > Van,
> > >
> > >
> > > Please Tom's comment, it's indeed as he writes.
> > >
> > >
> > > Tom,
> > >
> > >
> > > Thanks much for your feedback.
> > >
> > >
> > > To all those who are on the standard committee or have
> > > interactions with someone who's on the committee:
> > >
> > >
> > > Is it possible for someone to give the suggestion in my
> > > original post some thought?
> > >
> > >
> > > Thanks,
> > > Vipul
> > >
> > > On Mon, Oct 24, 2016 at 4:58 PM, Clune, Thomas L.
> > > (GSFC-6101) <[log in to unmask]> wrote:
> > > Van,
> > >
> > > No - I think the poster actually wanted to use
> > > SELECT CASE. He has provided a parameter ‘foo’,
> > > and wants to check if it is the same value as
> > > ‘bar’. Although inheritance was used, all of the
> > > variables are of type ’t’.
> > >
> > > One can overload ‘==‘ in Fortran, but SELECT CASE
> > > is currently limited to only a subset of intrinsic
> > > types. I’ve not seen any proposals for
> > > extensions to derived types.
> > >
> > > - Tom
> > >
> > >
> > > > On Oct 24, 2016, at 4:23 PM, Van Snyder
> > > <[log in to unmask]> wrote:
> > > >
> > > > If I understand your question correctly, what
> > > you want to use is SELECT
> > > > TYPE instead of SELECCT CASE.
> > > >
> > > > On Mon, 2016-10-24 at 16:11 -0400, Vipul Parekh
> > > wrote:
> > > >> I would like to be able to use some of my OO
> > > 'classes' (derived types)
> > > >> in SELECT CASE constructs like so:
> > > >>
> > > >>
> > > >> -- begin pseudo code snippet --
> > > >> program p
> > > >>
> > > >>
> > > >> use m, only : t, foo
> > > >>
> > > >>
> > > >> type(t) :: bar
> > > >>
> > > >>
> > > >> ! The following is not possible with even
> > > proposed Fortran 2015
> > > >> draft
> > > >>
> > > >> !select case ( bar )
> > > >> ! case ( foo )
> > > >> ! print *, "bar == foo"
> > > >> ! case default
> > > >> ! print *, "bar /= foo"
> > > >> !end select
> > > >>
> > > >>
> > > >> stop
> > > >>
> > > >>
> > > >> end program p
> > > >> module m
> > > >>
> > > >>
> > > >> use, intrinsic :: iso_fortran_env, only :
> > > ISO_FORTRAN_ADT,
> > > >> ISO_FORTRAN_IGETHASHCODE
> > > >>
> > > >>
> > > >> implicit none
> > > >>
> > > >>
> > > >> private
> > > >>
> > > >>
> > > >> type, extends(ISO_FORTRAN_ADT), public :: t
> > > >> private
> > > >> integer :: m_i = 42
> > > >> contains
> > > >> private
> > > >> procedure(ISO_FORTRAN_IGETHASHCODE),
> > > pass(this) :: get_hash_code
> > > >> end type t
> > > >>
> > > >>
> > > >>
> > > >> type(t), parameter, public :: foo = t( m_i=99
> > > )
> > > >>
> > > >>
> > > >> contains
> > > >>
> > > >>
> > > >> subroutine get_hash_code( this )
> > > result( hash_code )
> > > >>
> > > >>
> > > >> class(this), intent(in) :: this
> > > >>
> > > >> integer :: hash_code
> > > >>
> > > >>
> > > >> hash_code = ..
> > > >>
> > > >>
> > > >> return
> > > >>
> > > >>
> > > >> end subroutine get_hash_code
> > > >>
> > > >>
> > > >> end module m
> > > >>
> > > >> -- end pseudo code snippet --
> > > >>
> > > >>
> > > >>
> > > >> Is there any proposal/discussion in a future
> > > Fortran revision that
> > > >> will allow the above?
> > > >>
> > > >>
> > > >> I wonder if the standard were to introduce some
> > > "intrinsic" abstract
> > > >> derived type (say ISO_FORTRAN_ADT) with some
> > > deferred type-bound
> > > >> procedure, say ISO_FORTRAN_IGETHASHCODE, that
> > > provides an integer
> > > >> (default kind even) function result with a hash
> > > code for the type and
> > > >> I extend my types from this abstract to supply
> > > a hash code for the
> > > >> type, then why can't the SELECT CASE construct
> > > be allowed to operate
> > > >> on such derived types in addition to the
> > > current facility to work with
> > > >> integer, logical, and real intrinsic types?
> > > >>
> > > >>
> > > >> Thanks,
> > > >> Vipul Parekh
> > >
> > >
> > >
> >
> >
> >
> >
>
>
|
