File: f2j_TODO.txt

package info (click to toggle)
f2j 0.8.1+dfsg-5
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, sid
  • size: 3,152 kB
  • sloc: ansic: 18,992; java: 3,987; yacc: 3,804; sh: 153; makefile: 149
file content (50 lines) | stat: -rw-r--r-- 2,369 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
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
   remember correctly.
   [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.]

-Threadsafe version
   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.