Scope and specifications

The GOOL system aims to translate real world OOP languages into real world OOP languages. Currently the GOOL system only takes Java as its input language. It produces Java, C# and C++ as its output languages. This will evolve.

However, since real world OOP languages are very rich, the GOOL system cannot handle any such input language in its entirety. So the obvious questions are:

• What happens when it cannot translate?
• How much can it translate?
• How well does it translate?

What happens when it cannot translate?

The GOOL system proceeds in two steps:

• recognition of the input concrete language into the abstract GOOL language.
• generation of the output concrete language from abstract GOOL language.

So, what should the GOOL system do when an element of the input language is not recognized? Or when it is recognized, but not generated in the requested target language? Instead of blocking the entire translation process, it should pass on that instruction, i.e. pass it on from one language to another, almost textually, having performed just the syntactic changes that are generic, together with a comment: /* Unrecognized, passed on by GOOL */ or /* Not generated, passed on by GOOL */.

How much can it translate?

Well, concrete languages divide up into :

• The core (e.g. flow of control, primitive types, declaration, instanciation, etc.)
• The libraries (e.g. printing, file system, etc.) Generally speaking, the GOOL system ought to handle a large part of the constructs, but will only ever handle a small fraction of the libraries. However, it provides a simple mechanism for extending libraries support.

How much of the core is covered by the GOOL system ?

Rougly speaking, currently the GOOL system deals with:

• primitive types
• expressions, ifs, whiles, fors
• method declarations, calls
• variables declarations, initialization, assignments
• class declarations, constructors, instantiations, packages
• Tables

To be more precise:

• In order to know what subset of OOP languages constructs can be represented in abstract GOOL, explore the gool.ast.constructs and gool.ast.type packages.
• In order to know what subset of constructs of some input language xxx gets recognized into abstract GOOL, look at the content of gool.recognizer.xxx.xxxRecognizer.java file.
• In order to know what subset the GOOL abstract language gets generated into some output language yyy, look at the content of the gool.compilator.yyy.yyyGenerator.java file.

Which libraries are covered by the GOOL system ?

Roughly speaking, currently the GOOL system deals with:

• Hard-coded: Printing to the screen, Executing a system command, Lists, Maps
• Soft-coded: Files

For hard-coded libraries support:

• In order to know what subset of OOP languages libraries can be represented in abstract GOOL, explore the gool.ast.system, gool.ast.map, gool.ast.list packages.
• In order to know what subset of libraries of some input language xxx gets recognized into abstract GOOL, look at the content of gool.recognizer.xxx.xxxRecognizer.java file.
• In order to know what subset the GOOL abstract language gets generated into some output language yyy, look at the content of the gool.compilator.yyy.yyyGenerator.java file.

Actually, a library manager has been added that allows the user himself to easily specify the recognition and generation of some new libraries, just through some configuration files. Thus, for soft-coded libraries support check out:

• In order to know what subset of OOP languages libraries can be represented in abstract GOOL, explore the gool/classdeclarations directory.
• In order to know what subset of libraries of some input language xxx gets recognized into abstract GOOL, explore the gool/recognizer/xxx/matching directory.
• In order to know what subset the GOOL abstract language gets generated into some output language yyy, explore the gool/generator/yyy/matching directory.

How rigorously does it translate?

Even instructions that are named the same in different languages, can have different semantics (i.e. meanings) in the languages. For instance, tables in Java follow the same notation as in C++. Yet, in Java tables are guarded (one cannot go past the last element) whereas in C++, they are not. When we translate Java to C++, what should we do: privilege rigour and provide guarding mechanisms in C++, or privilege clarity and translate to unguarded C++ tables?

The problem if we had chosen the rigorous option would be twofold:

• the produced code would be unreadable,
• when translating C++ to some other language, tables become unguarded, but the intermediate abstract GOOL language would remain the same.

Following these remarks, we chose to opt for clarity to the expense of rigor. Hence, when translating from one OOP language to another, we take the most natural, common sense way of doing it. In this example this means translating Java tables by C++ tables. After all, their semantics is the same so long as the program does not go past the last element. Generally speaking, we assume that all programs to be translated are written in good style, avoiding non-standard cases.

Bottom line

The bottom line is that the GOOL system always produces clean code, with comments where it did not know. The programmer can then continue to translate manually: the systematic and boring part of the work has been done.