This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gfortran feature request: internal procedures as actual arguments


Paul Thomas wrote:
On Jul 29, 2007, at 10:03 PM, Steve Kargl wrote:
If you need threads, I'd suggest you take a look at Dan Nagle's
pthread module at http://users.erols.com/dnagle/pub/pthread.f03
instead of cramming a (possibly) nonstandard feature into gfortran.

Yup, I know about threads (we were using them back in the 70's at Xerox PARC). And as I mentioned in my first email, I can setup critical sections and use globals as a less than wonderful work around. But it makes it difficult to setup dynamic libraries.

One of the nice things about the fortan standard is that it leaves room
for compiler builders to be creative and go beyond the basic standard.
That's what Intel has done in this case, and that's what I'm still hoping you will decide to do also.
In this case, in my judgement, the standard designers had a very clear reason for not allowing this. Creativity is fine but we want, as well, that our users can depend on code being portable. We have a fairly realistic view of why folk might use open source F95 compilers......

As a fun diversion I'd only like to point out that the Fortran standard allows making all local variables SAVEd, i.e. put them in static memory. This would make pointers to contained functions trivial, and very functional, as one could even use them predictably when the containing function no longer has a stack frame, but nevertheless completely useless for Bill's purpose.


- Tobi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]