Vivek Rao wrote:
> An important counterexample to the conjecture that programming languages must continually evolve or die is C. C is very much alive, and Wikipiedia says
>
C actually is a good example. C lives and continues to evolve.
Cut/paste from the C committee web page:
"WG14 is revising the C99 standard, for a standard dubbed C1X. The
current draft of C1X as of 2010-06-25 is N1494. "
> "C89 is supported by current C compilers, and most C code being written nowadays is based on it"
>
Wikipiedia entries reflect the perspective of their authors. I've found
that there are people who demand C99 features. (And others who think
that gcc is the "true" C standard. :) ) The fact that lots of people
still use C89 is not a good reason to restrain the C committee from
revising C99. Same holds true for Fortran. Language standardization
takes a long time. By its very nature, it is always "ahead" of the
average user of the language.
Cheers,
Bill
> Sure, people can discuss Fortran standards beyond F2008, but it is highly premature to make decisions about such a standard when most of the Fortran community is still using Fortran 95 or earlier versions of the language.
>
> Vivek Rao
>
> --- On Fri, 8/6/10, Craig Dedo <[log in to unmask]> wrote:
>
>> From: Craig Dedo <[log in to unmask]>
>> Subject: Fortran Should Grow Not Go Into Maintenance (Was: Reusing an interface for procedure-type arguments)
>> To: [log in to unmask]
>> Date: Friday, August 6, 2010, 2:46 PM
>> Everyone:
>> Thanks, Bill for your insights.
>>
>> I strongly disagree with Vivek Rao's
>> recommendation that the Fortran Standards
>> Committee "should restrict itself to maintenance mode until
>> full F2008 compilers are
>> available".
>>
>> The problem with that approach is that
>> programming languages either continue to
>> move forward and therefore develop new features or they
>> die. There is no third option. A
>> programming language cannot remain in use if its
>> development is stagnant. If a language
>> stagnates, programmers will move on to other languages so
>> that they can meet current
>> needs.
>>
>> Come to think of it, the same is true
>> for human languages as well. Even Latin,
>> thought by many to be a dead language, continues to
>> grow. That is because Latin is the
>> official language of record for the Roman Catholic Church
>> and that church continues to
>> develop its vocabulary in order to keep up with current
>> needs.
>>
>> The reason is that there continue to be
>> new developments, especially in such
>> rapidly advancing fields such as software
>> development. E.g., one of the most important
>> recent developments is the rapid spread of the importance
>> of parallel processing. As
>> Fortran 2003 reached completion, parallel processing was
>> restricted to highly specialized
>> supercomputers, and therefore was a small niche area of
>> software development. During the
>> development of Fortran 2008, multi-core desktop and laptop
>> computers became widely
>> available. This development meant that parallel
>> processing became a mainstream need of
>> software development.
>>
>> Therefore, I would hope that the Fortran
>> Standards Committee starts thinking about
>> what features should be in the next version of the
>> language. Most likely, several members
>> already have a large list of desirable features, some of
>> which were dropped or scaled back
>> during the development of Fortran 2008.
>>
>> Comments, anyone?
>>
>> Sincerely,
>> Craig T. Dedo
>> 17130 W. Burleigh Place
>> P. O. Box 423 Mobile
>> Phone: (414) 412-5869
>> Brookfield, WI 53008-0423 E-mail: <[log in to unmask]>
>> USA
>> Linked-In: http://www.linkedin.com/in/craigdedo
>>
>>> -----Original Message-----
>>> From: Fortran 90 List [mailto:[log in to unmask]]
>> On Behalf Of Bill
>>> Long
>>> Sent: Friday, August 06, 2010 10:29
>>> To: [log in to unmask]
>>> Subject: Re: Reusing an interface for procedure-type
>> arguments
>>> Vivek Rao wrote:
>>>> Especially someone who has proposed many features
>> in Fortran 2008 should be
>>>> aware that several compiler vendors have decided
>> not to produce compilers beyond
>>> Fortran 95 (except for some TR's). Silverfrost is one
>> example. Lahey, which allied
>>> with Fujitsu, is another. Maybe someone can comment
>> about Pathscale.
>>> I believe that Pathscale is planning to continue
>> forward. Vendor
>>> decisions are influenced by customer demand. If
>> customers get
>>> accustomed to using the new features in F03 and F08,
>> vendors who want
>>> their business can change their minds about what they
>> will provide.
>>>
>>>> Fortran 2008 has been finalized, right? The
>> committee should restrict itself to
>>> maintenance mode until full F2008 compilers are
>> available.
>>> I would expect full F08 compilers to be available by
>> the end of 2011.
>>> The committee could spend the next year or so doing
>> maintenance
>>> (interps, finishing active TR projects) and then
>> start prioritizing new
>>> features in 2012. I don't get to make that
>> decision, but it seems like
>>> a reasonable schedule to me.
>>>
>>> Cheers,
>>> Bill
>>>
>>>
>>>> Vivek Rao
>>>>
>>>> --- On Thu, 8/5/10, Van Snyder <[log in to unmask]>
>> wrote:
>>>>> From: Van Snyder <[log in to unmask]>
>>>>> Subject: Re: Reusing an interface for
>> procedure-type arguments
>>>>> To: [log in to unmask]
>>>>> Date: Thursday, August 5, 2010, 7:07 PM
>>>>> On Thu, 2010-08-05 at 15:51 -0700,
>>>>> Tobias Brandt wrote:
>>>>>> Thank you very much for your quick
>> answer. At least
>>>>> now I know I don't
>>>>>> have to search for a Fortran 90 solution
>> any longer.
>>>>> :-)
>>>>>
>>>>> According to the table in ACM Fortran Forum,
>> several
>>>>> Fortran compilers,
>>>>> that is, the most widely used ones (Cray,
>> g95, gfortran,
>>>>> IBM, Intel,
>>>>> NAG) have implemented abstract interfaces and
>> procedure
>>>>> pointers. Sun
>>>>> apparently has not. Many of those have
>> made
>>>>> significant progress toward
>>>>> complete compliance with the 2003 standard,
>> and have even
>>>>> implemented a
>>>>> few features of the 2008 standard.
>>>>>
>>>>> You would have to contact PGI, Pathscale,
>> Silverfrost,
>>>>> Fujitsu...
>>>>> directly to ask them how much of Fortran 2003
>> or 2008 they
>>>>> support.
>>>>>
>>>>>> On 6 August 2010 00:40, Van Snyder <[log in to unmask]>
>>>>> wrote:
>> Tobias:
>>>>>> It's
>> not
>>>>> possible in Fortran 90 or Fortran 95, but in
>> Fortran
>>>>>> 2003
>> or
>>>>>> Fortran
>> 2008 you
>>>>> can define an abstract interface thus:
>>>>>>
>> abstract interface
>> subroutine F
>>>>> ( Arg )
>> real
>>>>> :: Arg
>> end
>>>>> subroutine F
>> end interface
>>>>>> You can
>> then
>>>>> access that interface either within the same
>>>>>> scope
>> as its
>> definition, or
>>>>> by use or host association, and declare a
>> procedure
>> pointer,
>>>>> procedure dummy argument, or type-bound
>> procedure by
>> reference
>>>>>> to it:
>>>>>>
>>>>>>
>> subroutine Some_Sub
>>>>> ( A, My_F )
>> real :: A
>> procedure(F)
>>>>> :: My_F
>> ....
>> end subroutine
>>>>> Some_Sub
>>>>>> See
>> subclauses
>>>>> 4.5.3, 4.5.4, 12.3.2.1 and 12.3.2.3 of
>>>>>> http://j3-fortran.org/doc/year/04/04-007.pdf.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On
>> Thu,
>>>>> 2010-08-05 at 15:09 -0700, Tobias Brandt
>> wrote:
>>>>>> > Hi
>> all,
>>>>>> >
>> I'm just
>>>>> starting out with Fortran 90 coming from C++
>> and
>>>>>> need
>> some
>>>>>> >
>> help. In
>>>>> C++ you can define a function pointer type
>> like so:
>>>>>> >
>>>>>> >
>>>>>> >
>> typedef
>>>>> void (*mytype) (float);
>>>>>> >
>>>>>> >
>>>>>> >
>> and then
>>>>> use it as a type for function parameters:
>>>>>> >
>>>>>> >
>>>>>> >
>> void
>>>>> some_function (float a, mytype f)
>>>>>> > {
>>>>>> >
>>>>> f(a);
>>>>>> > }
>>>>>> >
>>>>>> >
>>>>>> >
>> void
>>>>> some_other_function (float a, mytype f)
>>>>>> > {
>>>>>> >
>>>>> f(2*a);
>>>>>> > }
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>> Now, if I
>>>>> want to do the same in Fortran 90, I have to
>>>>>> define
>> the same
>>>>>> >
>> inteface
>>>>> twice:
>>>>>> >
>>>>>> >
>>>>>> >
>> subroutine
>>>>> some_sub (a, f)
>>>>>> >
>>>>> real :: a
>>>>>> >
>>>>> interface
>>>>>> >
>>>>> subroutine f
>> (arg)
>>>>>> >
>>>>> real
>> :: arg
>>>>>> >
>>>>> end subroutine
>>>>>> >
>>>>> end interface
>>>>>> >
>>>>> call f(a)
>>>>>> >
>> end
>>>>> subroutine
>>>>>> >
>>>>>> >
>>>>>> >
>> subroutine
>>>>> some_sub (a, f)
>>>>>> >
>>>>> real :: a
>>>>>> >
>>>>> interface
>>>>>> >
>>>>> subroutine f
>> (arg)
>>>>>> >
>>>>> real
>> :: arg
>>>>>> >
>>>>> end subroutine
>>>>>> >
>>>>> end interface
>>>>>> >
>>>>> call f(2*a)
>>>>>> >
>> end
>>>>> subroutine
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > Is
>> it
>>>>> possible to somehow "reuse" the interface
>> definition
>>>>>> by
>>>>>> >
>> declaring
>>>>> it outside the subroutines or in a different
>> module?
>>>>>> >
>>>>>> >
>>>>>> >
>> Regards,
>>>>>> >
>> Tobias
>>>>>>
>>>>>>
>>> --
>>> 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
>>
--
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
|