Skip to content

Scope and specifications

Jump to bottom
pja35 edited this page Nov 14, 2017 · 1 revision

The GOOL system aims to translate real world OOP languages into real world OOP languages. Currently the GOOL system only takes Java or C++ as input language. It produces Java, C#, C++ and Python as output languages. Actually the C++ input language recognizer is quite new and only works for simple input syntaxes.

However, since real world OOP languages are very rich, the GOOL system cannot handle any such input languages in their 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, instantiation, 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, if, while, for
  • 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 packages.
  • In order to know what subset of constructs of some input language XXX1 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 YYY2, look at the content of the gool.compilator.YYY.YYYGenerator.java file.

Which libraries are covered by the GOOL system ?

Currently the GOOL system deals with:

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

Nevertheless libraries are not yet supported by the C++ recognizer. It only works for the java input language.

Concerning the supported hard-coded libraries:

  • 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 XXX1 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 YYY2, look at the content of the gool.compilator.YYY.YYYGenerator.java file.

When a library is not hard coded, there is a way to associate a library of an input language with a GOOL abstract library that can be associated with explicit output files for each output languages.

  • In order to know what subset of libraries of some input language XXX1 gets recognized into abstract GOOL, explore the src/main/resources/gool/recognizer/XXX/matching directory.
  • In order to know what subset the GOOL abstract language gets generated into some output language YYY2, explore the src/main/resources/gool/generator/YYY/matching directory.
  • One can also specify more specifically the content of the GOOL abstract libraries by the mean of configuration files. Those files are given in the src/main/resources/gool/library directory. By now only the dependencies are working.

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 rigor 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: GOOL aims to help doing the systematic and boring part of the work.

1: We use XXX to denote an input language (cpp or java)

2: We use YYY to denote an output language (cpp, java, csharp or python))

Clone this wiki locally