<div><div class="gmail_quote">On Thu, May 3, 2012 at 1:55 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
In order to support our users who have Fortran codes, I would like to<br>
start working on adding Fortran support into clang. While at first this<br>
may seem like an odd fit, I think that it should work well for two<br>
reasons:<br>
<br>
 1. Most modern Fortran codes actually rely on the C preprocessor, and<br>
 so almost all Fortran compilers provide some kind of "integrated" C<br>
 preprocessor (often with some slightly different main-source<br>
 tokenization rules). For those of you who are not familiar, the<br>
 convention is that .f, .f90, etc. are plain Fortran files<br>
 while .F, .F90, etc. require the C preprocessor. clang has a good<br>
 preprocessor implementation, a lot of machinery for dealing with<br>
 parsing on top of the preprocssor and providing good errors and<br>
 warnings in the presence of macros. Reusing clang's capabilites here<br>
 makes a lot of sense.<br></blockquote><div><br></div><div>I think this idea may have some merit. A 'Fortran preprocessor' mode for the Clang preprocessor doesn't seem like an inherently bad idea, so long as it doesn't get in the way of performance or maintenance of the preprocessor as it is used by the C frontend.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 2. Modern Fortran is actually very similar to C++. It provides modules<br>
 (which are very much like C++ namespaces), types (which are very much<br>
 like C++ classes), operator overloading, etc. The control-flow<br>
 structures and built-in types are very similar between the two<br>
 languages; almost all of the differences are syntactical. As a<br>
 practical matter, Fortran is the "other" high-performance language. It<br>
 would make a lot of sense to reuse the AST->LLVM code in clang, as<br>
 much of it will be identical for Fortran.<br>
<br>
My idea is to modify the Lexer to support Fortran tokenization, and<br>
create a Fortran parser. This parser will, for the most part, map the<br>
Fortran code onto the C++ AST.</blockquote><div><br></div><div>This is very much in conflict with the design goals of Clang. We go to great pains to exactly represent the form of the code in the AST, and using the existing nodes to represent Fortran would really not fit.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In doing so, we can even reuse a lot of<br>
the semantic-analysis code.</blockquote><div><br></div><div>I would be very surprised if that's true. Not knowing Fortran myself, I've taken a look through the standard, and none of it seems particularly similar to the rules of C++. Certainly not similar enough that the C++ rules would provide the same results. And reusing the C++ semantic analysis would mean producing the C++ diagnostics, which would be entirely inappropriate.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Please let me know what you think.<br></blockquote><div><br></div><div>I think a Fortran frontend would be great to have in LLVM. If you intend to produce a high-quality frontend (one which to Fortran is as Clang is to C and C++), then I think any attempt to share Clang's parser, AST or semantic analysis would be to the detriment of your project (and to Clang). However, following the structure of Clang, and even drawing inspiration from its representation of types, expressions, etc., seems like a sensible approach.</div>
</div></div>