>>>>> "Alvaro" == Alvaro Agustin Fernandez <[log in to unmask]> writes:
Alvaro> Tom Clune wrote:
>> What I'm interested in is using some sophisticated
>> preprocessor to automate most of the work and thereby
>> effectivel provide F95 with the ability to have abstract base
>> classes. One could then declare classes (and their lineage),
>> and the preprocessor would create an appropriate set of Fortran
>> modules with corresponding derived types. The preprocessor
>> would have to do much of the same work that C++ compilers must
>> do, and we may even be able to leverage some of the code from
>> public compilers ...
>>
Alvaro> Out of curiosity - would you consider writing the
Alvaro> preprocessor itself in Fortran? There is at least one
Alvaro> preprocessor like that (fppr (?) ). Also, would you try to
Alvaro> "respect" the F2K syntax, so you don't end up with another
Alvaro> conversion issue later? Or would you use some other syntax
Alvaro> which might be easier to implement?
Alvaro> Alvaro Fernandez
I am certainly not wed to the idea of using PERL, but my guess is
that it would be a more suitable language for the preprocessor
than fortran per se. Another responder suggested using m4.
Several responders have suggested preserving the F2K syntax, and
I'm certainly going to keep that in mind. I've only skimmed the F2K
draft thus far, but it is not clear to me just how much of the OO
functionality it actually provides. To "extended" objects inherit
methods from the parent object, or just the components? On a more
fundamental level, the F2K standard leaves modules and derived types
relatively decoupled, whereas my idea was to force OO design by
strongly coupling modules and derived types via "classes". Using
something closer to C++ syntax has the additional benefit of making
the code more accessible to the computer science types who will be
designing the framework.
Ultimately, my instinct is that by the time I implement a preprocessor
of this power, converting it to accept a different syntax (F2K <->
C++) will be relatively easy. The important part is for the "client"
code to have an unambiguous manner for referring to the automated
derived objects/modules. This should easily be made independent of
the "higher" level specification of the classes.
Cheers,
- Tom
--
--
Thomas Clune, Ph.D. Parallel Applications Consultant
SGI [log in to unmask]
Code 931 NASA GSFC 301-286-4635 (work)
Greenbelt, MD 20771 301-286-1634 (fax)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|