Libraries support
The GOOL library manager is the new, preferred solution for the ''soft-coded'' recognition and generation of libraries (classes and their method calls). By means of configuration files, you can :
- define abstract GOOL library classes (which are organized in packages) and their methods
- match them with concrete classes / methods in the input language
- match them with concrete classes / methods in the output language, possibly using extra output language implementations files.
Thus, the user does not need to have an accurate knowledge of the inner workings of the GOOL system. The solution is modular, as it respects the core versus libraries duality.
All these files are located into the gool/library directory.
There is one class declaration file for each abstract GOOL library class. Its name is the name of the class. GOOL library classes are organized in packages. For example, the declaration of the GOOL class io.GoolFile is located in the file gool/library/io/GoolFile.
These files contain 4 types of declarations :
- Field declarations :
Syntax: [field] <name> : <GoolType>
where <name> is the field name and <GoolType> is either the full name (e.g. io.GoolFile) of a GOOL library class, or a type implemented in the gool.ast.type package (e.g. GoolString).
- Constructor declarations :
Syntax: [constructor] <GoolClassName> ( <list of comma-separated GoolTypes> )
where <GoolClassName> is the short name (e.g. GoolFile) of the current GOOL library class and <list of comma-separated GoolTypes> a list of parameters types as above.
- Method declarations :
Syntax: [method] <methodname> ( <list of comma-separated GoolTypes> ) : <return GoolType>
where <methodname> is the name of the method (e.g. createNewFile), <list of comma-separated GoolTypes> a list similar to those in the constructor declarations, and <return GoolType> a type as above.
- GOOL library class dependency declarations :
Syntax: [dependency] <GoolClassName>
where <GoolClassName> is the full name of a GOOL library class (e.g. io.GoolFile) that is required by the current GOOL library class to work. For example, io.GoolBufferedReader needs the GOOL library class io.GoolFileReader for its implementation to work in the target language. That is why io.GoolFileReader is a dependency of io.GoolBufferedReader.
GOOL dependencies are used to perform two different tasks within GoolClassAstBuilder.java:
When loading a GOOL library class as an AST, all dependent GOOL library classes will also be loaded as AST and registered as its RecognizedDependencies. All these ASTs are added to the current set of ASTs (stored within the input language's Recognizer) and they will play a role in the output language generation.
All of these files are located into the gool/recognizer/xxx/matching directory, where xxx is some input language. Their use is to map input language libraries onto GOOL libraries.
There is just one of these files for each input language.
The file, named ImportMatching.properties is located at the root: gool/recognizer/xxx/matching.
Each line of this file matches a GOOL library class name on the left hand side, with one or several imports from the input language on the right hand side.
Syntax: <GoolClassName> <- <comma-separated list of input language imports>
where <GoolClassName> is the full name of a GOOL library class (e.g., io.GoolFile) and <comma-separated list of input language imports> a list of imports (e.g. java.io.File, java.io.*), which may include the keyword default to represent the default input language library (e.g. stand for java.System).
If one import of the right hand side appears in the input program, then the recognition of the corresponding GOOL class and its methods will be activated. So, this is just a specific-translation enabler: its main role is to load up the next two tables.
# Example :
io.GoolFile <- java.io.File # Direct mapping
+io.File <- io.File # Indirect mapping require file gool/recognizer/java/matching/io/File.java
io.GoolFile <- io.File # Indirect mapping require file gool/recognizer/java/matching/io/File.java
# Where import(io.GoolFile) is in the Gool Ast and import(java.io.File) is in the input Java Ast.
There is one of these files per input language and GOOL final package (i.e., that does not contain any other GOOL package).
Each file, named ClassMatching.properties must be located in the subdirectory of gool/recognizer/xxx/matching corresponding to the GOOL final package of the GOOL library classes that is matches.
Each line of this file contains matches a GOOL library class on the left hand side, with one or several concrete input language classes on the right hand side.
Syntax: <GoolClassName> <- <comma-separated list of input language classes>
where <GoolClassName> is the full name of a GOOL library class (e.g., io.GoolFile) and <comma-separated list of input language classes> a list of full names of concrete classes in the input language (e.g. java.io.File).
If an expression typed with one of the class of the right hand side appears in the input program, then it will be recognized as the corresponding GOOL library class in the abstract GOOL language. This corresponding GOOL library class will be registered in the RecognizedDependencies of the current class.
# Example :
io.GoolFile <- java.io.File # Direct mapping
io.GoolFile <- io.File # Indirect mapping require file gool/recognizer/java/matching/io/File.java
# Where new io.GoolFile(...) is in the Gool Ast and new java.io.File(...) is in the input Java Ast.
There is one of these files per input language and GOOL final package (i.e., that does not contain any other GOOL package).
Each file, named MethodMatching.properties must be located in the subdirectory of gool/recognizer/xxx/matching corresponding to the GOOL final package of the GOOL library classes of the methods that is matches.
Each line of this file contains a match with a GOOL library method on the left hand side, and one signature of a concrete method in the input language on the right hand side.
Syntax: <GoolMethodName> <- <InputLanguageMethodSignature>
where <GoolMethodName> is the full name of a GOOL library method (e.g. io.GoolBufferedWriter.write) and <InputLanguageMethodSignature> a string that identifies methods in the input language. Its format is chosen by the Recognizer of this language. Here is an example of a java method signature:
java.io.BufferedWriter.write(String,int,int):void
If a method, whose signature is one of those of the right hand side, appears in the input program, then it will be recognized as the corresponding GOOL library method in the abstract GOOL language. The corresponding GOOL containing library will be registered in the RecognizedDependencies of the current class.
# Example :
boolean io.GoolFile.exists() <- boolean java.io.File.exists()
boolean io.GoolFile.argument(int arg1,int arg2) <- java.io.File.argument(int arg1,int arg2)
boolean io.GoolFile.argumentOrdered(int arg1,int arg2) <- java.io.File.argumentOrdered(int arg2,int arg1)
boolean io.GoolFile.argumentDefault(int arg1,int arg2) <- java.io.File.argumentDefault(int arg1,"1222")
# Where io.GoolFile..methodGool(...) is in the Gool Ast and java.io.File.methodJava(...) is in the input Java Ast.
All of these files are located in the gool/generator/yyy/matching directory, where yyy is an output language. Their use is to map GOOL libraries onto output language libraries.
There is one of these files per output language and GOOL final package (i.e., that does not contain any other GOOL package).
Each file, named ImportsMatching.properties must be located in the subdirectory of gool/generator/yyy/matching corresponding to the GOOL final package of the GOOL library classes that it matches.
Each line of this file contains a match with a GOOL class on the left side, with one or several imports from the output language on the right hand side.
Syntax: <GoolClassName> -> [+]<comma-separated list of input language imports>
where <GoolClassName> is the full name of a GOOL library class (e.g., io.GoolFile) and <comma-separated list of output language imports> a list of imports (e.g. java.io.File, java.io.*).
When generation the code for the dependencies (i.e. the imports) of some abstract class, its RecognizedDependencies will be mapped into output language imports via this file.
However, some of these imports may not actually be part of the standard library of the output language (e.g. io.GoolFileImpl). These must be preceded by a plus, indicating that an implementation file (e.g. GoolFileImpl.java) is provided. This is referred to as the "indirect usage". The provided implementation file must be indeed present in this same directory. It will be copied along the output to the GOOL system if needed, in the subdirectory that corresponds to the GOOL final package.
# Example :
io.GoolFile -> java.io.File # Direct mapping
io.GoolFile -> +io.File # Indirect mapping require file gool/generator/java/matching/io/File.java
# Where import(io.GoolFile) is in the Gool Ast and import(java.io.File) is in the input Java Ast.
There is one of these files per output language and GOOL final package (i.e., that does not contain any other GOOL package).
Each file, named ClassMatching.properties, must be located in the subdirectory of gool/generator/yyy/matching corresponding to the GOOL final package of the GOOL library classes that it matches.
Each line of this file contains a match with a GOOL library class on the left side, and a single concrete class in the output language on the right hand side.
Syntax: <GoolClassName> -> <concrete output language class>
where <GoolClassName> is the full name of a GOOL class (e.g. io.GoolFile) and <concrete output language class> a short name of a concrete class in the output language (e.g. java.io.File).
When generating the code for a GOOL library class, its gets mapped into an output language class via this file.
# Example :
io.GoolFile -> File # Direct mapping
io.GoolFile -> FileImpl # Indirect mapping require file gool/generator/java/matching/io/FileImpl.java
# Where new io.GoolFile(...) is in the Gool Ast and new java.io.File(...) is in the output Java Ast.
There is one of these files per input language and GOOL final package (i.e., that does not contain any other GOOL package).
Each file, named MethodMatching.properties must be located in the subdirectory of gool/generator/yyy/matching corresponding to the GOOL final package of the GOOL library classes of the methods that is matches.
Each line of this file contains a match with a GOOL library method on the left hand side, and one signature of a concrete method in the input language on the right hand side.
Syntax: <GoolMethodName> -> <OutputLanguageMethodSignature>
where <GoolMethodName> is the full name of a GOOL library method (e.g. io.GoolBufferedWriter.write) and <InputLanguageMethodSignature> the short name signature in the output language. Its format is chosen by the Recognizer of this language. Here is an example of a java method signature:
write(String,int,int):void
When generating the code for a GOOL library method, its gets mapped into an output language class via this file.
# Example :
boolean io.GoolFile.exists() -> exists()
boolean io.GoolFile.argument(int arg1,int arg2) <- argument(arg1,arg2)
boolean io.GoolFile.argumentOrdered(int arg1,int arg2) <- argumentOrdered(arg2,arg1)
boolean io.GoolFile.argumentDefault(int arg1,int arg2) <- argumentDefault(arg1,"1222")
# Where io.GoolFile..methodGool(...) is in the Gool Ast and java.io.File.methodJava(...) is in the ouuput Java Ast.
[The list of existing GOOL library.](Summary of existing GOOL library).