Relatively high priority modifications. (not necessarily listed
in order of priority)
-Isolate the WRITE/FORMAT code in the lexer into a subroutine.
-Work on front-end
The front-end of f2j is sufficient for BLAS/LAPACK code, but to
handle any other code it will have to be extended. I think the
best way to go would be to graft a full f77 parser from another
compiler or tool (such as FTNCHEK) onto f2j. This is no small
task since it could alter the structure of the syntax tree, thus
requiring all subsequent stages of the translator to be modified.
-Port fortran I/O library to java
I have a BSD fortran I/O library somewhere (written in C) that would
make translating READ,WRITE,FORMAT statements much easier - if only
it was converted to Java. It's around 6000 lines of C code, if I
[UPDATE: as of version 0.8, this is done to a certain extent, but
not from a C port. I integrated a hacked version of Jocelyn Paine's
Formatter package into f2j.]
One or two people have asked about this. It's not a bad idea, but
it would change the user interface and code generation. The code
that generates static initializers would need to be changed.
-Support more data types
Having support for complex numbers would be nice, but it will require
a lot of changes in the code generator.
-More translator optimizations
Might be interesting to see if we can optimize the array indexing
since it gets so cumbersome in the translation. The java compiler
probably optimizes the index expressions - however, even if it turns
out that there is no speed improvement, it would still help the
readability of the resulting source code a lot. If we end up
translating directly to Jasmin or bytecode, then we should definitely
try to optimize some of this. Also string operations (accessing a
single character, substring, etc) may leave some room for optimization.
-Create AST documentation
It would help to have a chart of the structure of each kind of
node in the abstract syntax tree.
-Create API documentation
Write some API documentation - something a little more extensive
than the current javadoc pages. There is a standard link
generated by javadoc, "API Users Guide", that should be linked
to the API docs whenever complete.