At the programming language level, the Tools perform three functions:
They extract the logic from existing programs for subsequent analysis in order to construct a model incorporating the program semantics.
They restructure the semantics of the programs.
They generate new code from the restructured language-level model. This new code may be in a different programming language.
Together, functions 2 and 3 constitute the code generation phase of creating programs based on a higher level model. On the other hand, all three functions taken together constitute a system which can either re-structure existing programs at a programming language level, or can translate or transcode existing programs from one programming language into another.
The rest of this explains program translation or transcoding; from that process, the way code is generated from models (explained elsewhere) should be obvious.
Rather than convert directly from one programming language to another, we first compile the input languages into a common language, Pangloss. Each input language requires a separate compiler, which captures the semantics of the input source file in the context of the language in which it is written. It also encodes dialectical differences among compilers, as well as the values of the compile-time options used to compile the original source code. The Pangloss source also contains the comments from the input source, as well as the source code itself; both the original comments and the original source, along with other annotations, may appear as comments in the final, translated source.
Pangloss isn't intended to be executed or run on any real machine: it is designed to express all that is possible in the source languages which we support. It is a dialect of Lisp, with extensions suitable for this job. Although it isn't meant to be a production language, it will, in fact, run for debug purposes. It's just not very efficient for production, because of the level of detail it incorporates. For instance, the addition operation must account for the size of the operands, how overflows are handled, and so on, so it's not a simple addition in any one programming language or for any specific platform: it must be parameterized to capture the semantics of the specific input language from which the Pangloss was generated.
A series of tools is then used to restructure and to optimize the Pangloss source file. In the future, we expect to provide a set of tools for refactoring and redesign, but at this time there is only the generic, vanilla restructuring tool.
Finally, a series of transcoders, one for each output language, generates the output source file for the target environment. The transcoders are configurable, and attempt to adhere as much as possible to the idioms normally used by the target language. Thus, the output language won't look as if it were simply line-by-line converted from the input. If the output is, for example, Java, we think it ought to look as if a Java programmer wrote it in the first place. Each Pangloss file may result in one or in multiple source code files, depending on the target language and platform.
Handling multiple source languages requires multiple compilers, and supporting multiple target languages requires multiple transcoders.
Note that our design allows the use of the same programming language as both input and output. Doing so will perform a clean-up operation on the logic, and perhaps a small amount of optimization.
We may release some compilers and transcoders initially with limitations, to be corrected later.
©2017 Ulterior Logic. Pangloss™ and Coyotemath™ are trademarks of Ulterior Logic.