> Date: Wed, 12 Nov 1997 10:47:36 -0600 (CST)
> From: "David B. Serafini" <[log in to unmask]>
> > Date: Wed, 12 Nov 1997 17:27:38 +0100 (MET)
> > From: Michael Metcalf <[log in to unmask]>
>
> > On Wed, 12 Nov 1997, Peter Bismuti wrote:
>
> > > Is there a flag that can allow one to override the 31 character
> > > limitation on the names of subroutines and functions? Any plans on
> > > extending the length in future standards?
> > >
> > > thanks
> > > _______________________________________________________________________
> > > | Pete Bismuti |
> > > | Supercomputer Computations Research Institute |
> > > | Florida State University - Department of Mathematics |
> > > | [log in to unmask] (904)644-6263 |
> > > |_____________________________________________________________________|
> > >
> > What a very bad idea! This works against portability.
>
>
> > Mike Metcalf
>
>
> The portability problem can be overcome quite simply. All you need is
> a utility (written in portable F90) that parses F90 code. From this
> it is almost trivial to write a program that takes code with longer
> symbol names and hashes them into standard length names and writes the
> code back out. Voila.
>
I got serious problems with systems not accepting external names longer
than 8, or 14, or 17 characters. So there is a serious portability
problem, and I would not recommend either to ``standardize'' that problem.
Writing a utility in portable F90 is not so simple. I can tell you for
sure, as I wrote one. If you don't have limits on the number of continuation
lines, on the line length, and on identifier length, you cannot achieve
acceptable performance, at least in the current state of the varying length
strings module implementation.
> In the spirit of the GNU and Linux efforts, I think we, the F90 community,
> should join together to produce a portable, free F90 code parser written in F90
> and use it to build tools such as this one. Once the parser is in place, most
> of the tools (a pretty printer that produced TeX output, for example, or a
> "lint" type of program checker, etc). If we all worked together on this, I bet
> we could do it in short order. I think most of the work has already been done
> in various places, it's just a matter of packaging it all together in a
> consistent form, developing and documenting an API, and distributing it.
>
_That_ is a good idea anyway. I volunteer to contribute.
Michel
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|