What to do next?

Generally speaking, GOOL can be extended in multiple manners:

• Extend the code recognition of the currently supported input language (Java, C++). The C++ input is far from being complete.
• Extend the code generation of the currently supported output languages (Java, C#, C++, Python). Objective C does also exist but is very poorly developed.
• Extend the support for libraries (Dynamic class loading...).
• Add input languages ( C#, Objective C, PHP, ...).
• Add output languages (Javascript, GO Lang, PHP, ...).
• If needed: extend the GOOL intermediate language which is the bridge between all these.
• Perform the recognition of the currently supported input language (C++), Todos are comments in the code explaining the bugs to be fixed.

Still, here are some suggestions of what could be done.

Extend code generation of the currently supported input language

• Case construct, Conditional expression...
• Instance of...
• Empty statement, Break, Continue, Do while, ...
• Abstract representation of exceptions, chained exceptions...
• Annotations.

(See recognizer.java.)

Extend code generation of the currently supported output languages

C++

• Libraries: all current soft libraries have to be rewritten. It does not correspond to C++ standards. For example all streams have to be properly defined.
• Dealing with the friend operators <<, >>.
• Dealing with the namespaces (std::).
• Dealing with constants (std::ifstream::binary).
• Dealing with pointers (classical, smart), references, copy, const...
• Properly deal with lonely functions (out of classes).
• Dealing with generic, lambda functions...
• Core: Fix exceptions (Currently, there is a syntax error in the generation of catch blocks: the declaration of the exception caught is wrong)

Objective C

• Libraries: Deal with I/O (From scratch)
• Core: Fix encapsulation of built-in type variables with object types in the code generation (Currently, the declaration of an integer is genered as int x in the output code. It should be NSInteger x.)
• Core: Fix foreach loops (This problem is a consequence of the previous one. As Integer objects are not properly generated, they currently cannot be used as loop index.)
• Core: Deal with exceptions (From scratch)

More input languages

• C#, Objective C (here is some parser).
• PHP (here is some parser).

More output languages

• Javascript, GO lang, ...

Add GOOL libraries and code generation for them:

• Dealing with Networks.
• Dynamic class loading (particularly challenging in C++).
• Forking processes and other concurrency functionalities.

This can be done in two ways (See How does it work?, Libraries support, the second is preferred when it is enough).

Transversal tasks

• Chase TODOs in the code.
• The GOOL library manager is explained in How does it work?, Libraries support and The library manager. Suggested improvements:
  • A more flexible and powerful syntax of the MethodMatching tables 2.3 & 3.3, allowing to reorder parameters, suppress them, put constants instead e.g. goolmethod(y,cst) -> targetmethod(y,x).
  • A slightly more powerful syntax of the ImportMatching table 2.1. This table tells which imports will be intercepted by the library manager, by loading the corresponding entries in the 2.2 and 2.3 tables. But since these tables are at final package levels, table 2.1 could be of the form gool final packages <- imports e.g. goolxxx.io.* <- java.io.*, more in the spirit of a package to package correspondence.
  • Handle library attribute access without methods.
  • Avoid the redundant java.io.*, java.io.File in the syntax of 2.1.
  • Parse methods and attributes of GOOL library classes in the GoolLibraryClassBuilder.

Overall tasks

• Clean the architecture. Some files are too large, non-modular: CodeGenerators, Recognizers. Recognizers can seem very different from one language to another, could it be unified/simplified? What happens if we add a third input language? There seems to be some unused classes, for instance in the gool/ast/core. If they are there to define the core of the language, shouldn't they be used?
• Tests. Use JUnit. Cover the library manager and make it more robust.