[cdt-dev] Thoughts on Fortran and Language Independence

[Jeffrey Overbey <overbey2@xxxxxxxx>]

Greetings all,

On behalf of the Photran team, I apologize that we haven't been 
responding to the discussions on Fortran and language independence.  In 
short, this is because we don't know what the "right" answer is 
(although we've discussed it a lot... see below).

My understanding is that our goal is to eventually have a 
language-neutral plug-in (CLDT/UDT/XDT) and separate plug-ins for C/C++, 
Fortran, and other compiled/gdb-able languages that extend it. 
(Maintaining Fortran support as part of the CDT codebase is out of the 
question for more reasons than I care to list.)

The majority of the changes between the CDT and Photran were textual 
substitutions in the user interface.   Making these language-neutral is 
easy... if it isn't C/C++-specific, put it in the CLDT UI, and make the 
name more generic.  We might have a Compiled Language Development 
Perspective, a generic Standard Makefile Project (shared by all 
languages), and a menu item to Run Local Binary Application.

In the code, though, we inherit a *lot* of functionality from the CDT, 
and separating the generic parts from the C/C++ or Fortran-specific 
parts is going to require some serious thought and discussion.  The 
editor is a great example.  A lot of it had to be customized... but we 
inherited the preference pages and user-specified syntax colors "for free."

I am not ready to tackle the topic of what to do with the 
ICModel/ICElement heirarchy.  Our current Outline view is more 
accurately called the Proof of Parser View, and our present concern is 
designing a refactorable AST/symbol table setup for a 31-page Fortran 95 
grammar (an annoyingly tedious and time-consuming task).  We disabled 
pretty much every form of browsing and and are basically ignoring the 
indexer, so beyond giving us an Outline, it isn't doing much for us 
anyway.  (Optimal?  No, but the thing works, and no one has complained!) 
 I believe that we could eventually have a single CLDT project type 
shared across multiple compiled languages, and (especially then) a 
hierarchy like this will be useful.  Reusing the C/C++ nodes to 
represent a Fortran program doesn't seem like the right answer, but 
neither is taking the union of features in C/C++ and Fortran, if we want 
to support other languages.  And I don't know that code well enough to 
suggest a better abstraction.

Below, I have pasted snippets of some e-mails between members of our 
team discussing our perspective on this issue and describing it in a 
little more detail.  In short, a CLDT is going to be worthwhile, but 
it's also going to require a significant amount of commitment and 
discussion both from us (including LANL) and the CDT team.  (And, if I'm 
lucky, a trip to Ottawa...)

=====

If I were to summarize our position on what we want from a 
language-neutral CDT, I think it would be...

(1) We don't care if we "plug into" the CDT or if we're a separate 
entity, as long as...

(2) Constructing Photran "properly" is not significantly more difficult 
or time-consuming than the present cut-and-paste routine, ...

(3) Upgrades to the CDT code base have a minimal effect on us; i.e., 
staying current with the CDT will be less work than cutting and pasting 
together a new hacked CDT each time, and ...

(4) All of the current features in Photran are still supported 
(including the New Fortran Project wizard and, if possible, a Fortran 
perspective).

Our goal is to work on automated refactorings for Fortran and HPC; 
Photran is simply a platform for this work.  Our reason for basing our 
code on the CDT was to get a lot of functionality "for free."  Our 
reason for wanting to "plug into" a language-neutral CDT is to reduce 
the cost of upgrading alongside the CDT -- essentially, to get upgrades 
"for free" as well.  A "hacked" CDT code base is not very pretty, but if 
it is the only economical way to do what we want to do, we'll take it.

Our approach of cloning the CDT, and subjecting it to a Fortran makeover 
has a number of advantages:

1) It can be accomplished quickly, at least the second time around, 
without a deep knowledge of Eclipse and the CDT's structure
2) Such an approach would allow Photran and a CDT to coexist in the same
workspace, hence allowing C and Fortran resources to coexist too
3) Maintaining our own modified codebase allows the CDT to evolve without us
4) It makes cosmetic changes trivial (search/replace)
5) It makes disabling non-applicable functionality feasible

This said, there are some downsides:

1) Tracking CDT changes requires that we redo all our modifications
2) The bulk of our code duplicates vast swaths of CDT code in all but a 
few superficial respects

The CDT folks, LANL folks, and we all agree that making the CDT more 
friendly to new languages is a worthwhile goal.

It would be nice were customization doable using XML and a few new, 
language-specific plug-ins.  Heading all the way towards plugging in a 
grammar and a few style sheets is a long way off, though.

Managed build, standard build, and some of the wizards are probably 
quite close to being customizable using XML forms only, were the 
plug-ins themselves sharable across perspectives.

There are likely a number of plug-ins where we changed only strings, and 
where a single "internationalization"-style effort would make them more 
reusable. The same disclaimer may apply.

There are yet other places where language dependencies are more 
difficult to avoid: lexing, parsing, editing, and, to some extent, 
browsing.  We may want to keep language-specific perspectives in the mix.

Adding "natures" to the CDT is not necessarily the answer.  In fact, 
having separate natures for C and C++ seems to be an incorrect use of 
the technology.  It might even be possible to have two project types 
(Standard and Managed Make), encompassing C/C++ as well as Fortran and 
other languages.

Eclipse is build out of plug-ins, and each plug-in is a singleton. Of 
course, these singletons can, in turn, wield such resources as they see 
fit to exhibit multiple personalities. We need to ponder how to best 
address this, I'm not ready to take a stand on the best way to do this yet.

Superficially, we would like to supply a Core and UI and tie into the 
CDT's facilities for Make, Launch, and Debug.  Of course, we don't want 
to *completely* build the Core and UI from the ground up.  Without 
really investigating what of this is already possible, some of the more 
interesting issues seem to be... (BTW, I probably left out some things, 
and these aren't very well thought out...)

1.For outlining, we would like to reuse part of what the CDT already 
has.  Building a TreeView from scratch should not be necessary.  If this 
means subclassing appropriately to build a model similar to theirs, I 
think that's a reasonable solution.

2.The editor... we get a LOT for free (e.g., associated preference 
pages), but we're also changing a lot (syntax highlighting, eventually 
many other things like content assist and auto-indentation).  Basically, 
we need a starting point that is richer than JFace Text.  (Note that we 
may eventually want to cut over to parser-guided syntax highlighting.)

3.The rest of our UI is coming for free (right?): the Fortran 
perspective, the Fortran project wizard, the import wizard, the 
preference pages, etc.  Somehow we should continue to get all that 
without any real effort.

4.We have many wondrous error parsers that need to plug into the 
(shared) Make system.  (I think this is already possible via extensions, 
but I haven't looked carefully, much less tried...)

5.To what extent is the CDT's indexer reusable?  Fortran Search could 
bring up some other interesting integration issues.

6.Our take-it-or-leave-it attitude toward gdb debugging probably won't 
suffice for other projects.

=====

Warm regards,

Jeff Overbey
University of Illinois at Urbana-Champaign
Software Architecture Group, Photran Team

<<End cdt-dev post with length rivaling _War and Peace_>>