1.1 Introduction
What are the strengthen of Jitran:
- Reliability when used correctly
- Modularity
- Determinism
- Testing option
- Adaptability
1.2 Overview
1.2.1 Pipeline
1.2.2 Language Modules
A Language Module is a Data Object that represents a language—either internally within Jitran or externally—in a way that is semantically and syntactically compatible with other languages. A language module exists externally as a file or directory and internally within Jitran as a data object or a Java object.
1.2.3 IR (Overview)
IR is the bridge between the languages. This means that the semantic information of the Input Language is contained within the IR nodes. The IRs are therefore the Data Object that contain all the semantic (1.3.1/semantics) information of the input language. There are different types of IRs, each of which may contain different IR nodes; for this reason, the entire Data Object is also called an IR Tree.
1.2.4 Syntax Defining (.jtx)
JTX stands for Jitran Syntax and is the language that defines the Syntax of a language. This information, which comes from JTX, is used by the Frontend and Backend to translate the language.
1.2.5 Front-/Backend
The Frontend and Backend are programs, which may be programmed to handle more complex logic and integrated into syntax.jtx. The frontend is used during the Transformation Stage, and the backend is used during the Generation Stage.
1.3 Terminology
1.3.1 Base Terms
must
Indicates a mandatory requirement. All statements using must are required for a valid implementation.
must not
Indicates a prohibition. All statements using must not are forbidden in a valid implementation.
should
Indicates a recommended requirement. Violating a should requirement may result in unintended behavior.
may
Indicates optional behavior. Implementations are free to follow or ignore it.
valid
An object is considered valid if it satisfies all applicable requirements defined in this specification.
defined
Indicates that an object is fully configured and usable within the Jitran Core.
deterministic
The process must be predictable and transparent. The same input produces the same output.
1.3.2 System Components
Language Module
A data format that contains all information required to translate a language using Jitran.
Jitran Core
The component that processes language modules and source code and produces output code.
Lexer
The component that converts raw input text (mostly Source Code) into a sequence of Tokens.
Parser
Renderer
The component that generates the Output Code based on IR.
Transformation Stage
The stage in which intermediate representations (IR) are processed and transformed.
Generation Stage
The stage in which the final output is generated from the IR.
Frontend
A user-defined component used to implement transformation logic during processing.
Backend
A user-defined component used to implement output generation logic.
Manifestdata / Language Module Metadata
General information about the language represented by the language module.
Directory Format
The directory format means that a object consists of files stored in a directory.
Internal Format
The internal format means that a object is loaded into Jitran Core as a data object.
1.3.3 Language Concepts
Syntax
The formal structure of a language.
Semantics
The meaning and behavior of a program during execution.
Syntax Element
A Data Object representing a specific syntactic structure.
Pattern
A structure that describes how source code is matched using Literals and Slots.
Literal
A fixed token in a Pattern that must match the source code exactly.
Slot
A placeholder within a Pattern that references a syntax element and captures a value.
Priority Order
The order in which the parser checks the syntax elements for a match.
Virtual Standard Library
A virtual standard library based on native functions and Library Core and used by every Jitran language.
VSLC (Virtual Standard Library Core) / Library Core
The statically defined core of the virtual standard library, which is based on native functions and uses no standard library other than the native functions.
Native Functions
Dynamic, language-defined basic functions of the virtual standard library.
JigsawScript
A highlevel, object-oriented, jitranbased programming language.
1.3.4 Data Structures
Token
A Data Object representing a fragment of the source code.
Data Object
An internal structure used to store and process information within the Jitran Core.
IR
Intermediate Representation. A structured representation of program semantics.
Language Module File
A completly language module compressed in one file.
1.3.5 Languages
Input Language
The language of the source code that is processed by Jitran.
Output Language
The language of the output code.
Source Code
The input code, which have to be translated by jitran.
Output Code
The code generated by Jitran.
Source Program
The input program, which have to be translated by jitran.
2.1 Pipeline
2.1.o Overview
Jitran's pipeline consists of various steps in which the source code is analyzed, converted to IR, and then the output is generated from the IR. The process of analyzing the source code written in the Input Language and converting it into IR nodes is described as the Transformation Stage. The process of generating the output code in the Output Language from the IR is referred to as the Generation Stage.
2.1.1 Lexer
Definition
The lexer converts a sequence of characters into a sequence of tokens based on the syntax of the input language.
Input
A sequence of characters representing the source code.
Output
A sequence of tokens.
Semantics
2.1.2 Parser
Definition
The parser consumes tokens and generates IRs based on syntax elements. The syntax elements are based on the language module of the input language.
Input
A sequence of tokens.
Output
A IR Tree.
Semantics
- The
parsermust process tokens in order (priority order). - The
parsermust be depending on syntax elements defined in the input language.
2.1.3 Renderer
Definition
The renderer gets the ir tree and generates a output string based on syntax elements. The syntax elements are based on the language module of the output language.
Input
A ir tree.
Output
Code as string
Semantics
- The
renderermust process irs in order (hierarchical direction). - The
renderermust be depending on syntax elements defined in the output language.
2.1.4 Transformation Stage
Definition
The Transformation Stage is the first part of the Jitran pipeline after the language modules and source code have been loaded; it converts the source code into IR. It consists of the lexer, the parser, and the frontend.
Input
A sequence of characters representing the source code.
Output
A IR Tree.
Semantics
- The
transformation stagemust go through individual steps in a strict sequence. - The
transformation stagemust be based on the input language. - The
transformation stagemust be deterministic. - The
transformation stagemay use the Language Module Metadata of the output language. - The
transformation stagemust not depend on syntax elements of the output language.
2.1.5 Generation Stage
Definition
The Generation Stage is the second part of the Jitran pipeline after the transformation stage has generated IR Nodes; it generates the output based on IR. It consists of the renderer, and the backend.
Input
A IR Tree
Output
An output code.
Semantics
- The
generation stagemust execute its components in a defined order. - The
generation stagemust be based on the output language. - The
generation stagemust be deterministic. - The
generation stagemay use the Language Module Metadata of the input language. - The
generation stagemust not depend on syntax elements of the input language.
2.2 Language Module
2.2.o Overview
A language module is designed to represent a language for Jitran. It must be in either directory format or internal format. It contains various data components.
2.2.1 Components
Components List
The following components must not be more than once.
| Component | Common Filename + File Extension | Short Discription | Reference |
|---|---|---|---|
manifest.jtm |
Contains general information about the language represented by the Language Module. |
||
syntax.jtx |
Contains syntax information about the language represented by the Language Module. |
||
native.jtn |
Includes the native functions for the virtual standard library |
||
frontend.jss |
Includes the custom frontend for semantics in transformation stage. |
||
backend.jss |
Includes the custom backend for semantics in generation stage. |
2.2.2 Directory Format
Definition
The Directory Format is used for developing a language module and includes the components listed above (2.2.1 Components). Each component listed above is represented by a file in a main directory. To use the Language Module it must compress the directories into a language module file (language-id.jtlm).
Semantics
2.2.3 Internal Format
Definition
The Internal Format means that the language module resides in the JVM as a java object, and all data is initialized as fields of that java object.
Internal Fields
All fields are final so they can not modify by other Language Modules.
All of the following fields refer to the language modules and represent java objects:
| Init & Constructor Index | Access-Id | Type | Short Discription | |
|---|---|---|---|---|
| 1 | syntax | LanguageSyntax | The syntax |
*** |
| 2 | id | String | The id-name |
*** |
| 3 | extension | String | The file extension |
*** |
| 4 | default_backend | String | The id of the default language tranlated to |
--- |
| 5 | author | String | The author |
--- |
| 6 | release_date | String | The release date |
Current date (Time of compilation) |
| 7 | description | String | The description |
--- |
| 8 | line_comment | String | The Linecomment |
--- |
| 9 | ignore_linebreak | boolean | If true the lexer do not generate linebreak tokens |
true |
| 10 | case_sensitive | boolean | If true the parse not irgnore individual cases |
true |
| 11 | re_declineble_methods | boolean | If true the language support redeclineble methods |
false |
| 12 | supported_backends | List<String> | Contains all supported backend language ids |
{} //= Every language |
| 13 | key_words | List<String> | keywords which represent the language. If a keyword represent an other language you can write |
{} |
| 14 | block_comment_start | String | The token that represent the start of an blockcomment |
--- |
| 15 | block_comment_end | String | The token that represent the end of an blockcomment |
--- |
| 16 | stdlib_version | float | The max compatible version of the virtual standard library |
--- //= Every |
| 17 | transpiler_version | float | The max compatible version of jitran |
--- //= Every |
| 18 | version | float | The version of the language |
1.0 |
| 19 | homepage | String | The URL of the homepage of the language |
--- |
| 20 | repository | String | The URL of the github repository of the language |
--- |
| 21 | forum_url | String | The URL of the forum |
--- |
| 22 | frontend | byte[] | The frontend as java bytecode |
{} |
| 23 | backend | byte[] | The backend as java bytecode |
{} |
| 21 | native_bridges | Bridge[] | The Native Functions |
*** |
2.3 Intermediate Representation (Overview)
2.3.o Overview
The IR (Intermediate Representation) serves as the sole medium of exchange between two language modules. In this process, the source program is passed semantically from the transformation stage to the generation stage.
2.3.1 Goal
The goal of IR is to capture the semantics of as many programs as possible written in as many languages as possible.
2.4 Frontend/Backend (Overview)
2.4.o Overview
Frontend
The frontend is a subprogram of Jitran that serves as userdefined logic for translating any logic in the transformation stage.
Backend
The backend is a subprogram of Jitran that serves as userdefined logic for translating any logic in the generation stage.
Language
Both are write in JigsawScript but are compiled in java bytecode.
2.5 Execution Model (Overview)
2.5.o Overview
The execution model of Jitran defines how the pipeline is executed to transform source code into output code.
Jitran executes its pipeline in a strictly ordered sequence of stages. Each stage consumes the output of the previous stage and produces a new intermediate result.
The execution is deterministic, meaning that the same input always produces the same output.
3.1 Manifestdata
3.1.o Overview
Overview
The Manifestdata is a component of a language module and contains the metadata of the. There are only one per language module.
In jitran the manifest data has an directory format and an internal format.
3.1.1 Directory Format
General
The Directory format consists of a file named manifest.jtm. The file is located in the root directory of the language module (in Directory Format).
Semantics
- The manifest filename must be end with
.jtm. - The manifest filename should be
manifest.jtm. - There must be only 1 manifest per language module.
3.1.2 Internal Format & Components
Internal Format
In the Internal Format, the manifest data is stored as a data object in Jitran Core.
Components
All following components representing java fields of the java class.
All components are final so they can not modify by other Language Modules.
All of the following components refer to the manifest and represent java objects:
| Access-Id | Type | Short Discription | |
|---|---|---|---|
| id | String | The id-name |
*** |
| extension | String | The file extension |
*** |
| default_backend | String | The id of the default language tranlated to |
--- |
| author | String | The autor |
--- |
| release_date | String | The release date |
Current date (Time of compilation) |
| description | String | The discription |
--- |
| line_comment | String | The Linecomment |
--- |
| ignore_linebreak | boolean | If true the lexer do not generate linebreak tokens |
true |
| case_sensitive | boolean | If true the parse not irgnore individual cases |
true |
| re_declineble_methods | boolean | If true the language support redeclineble methods |
false |
| supported_backends | List<String> | Contains all supported backend language ids |
{} //= Every language |
| key_words | List<String> | keywords which represent the language. If a keyword represent an other language you can write |
{} |
| block_comment_start | String | The token that represent the start of an blockcomment |
--- |
| block_comment_end | String | The token that represent the end of an blockcomment |
--- |
| stdlib_version | float | The max compatible version of the virtual standard library |
--- //= Every |
| transpiler_version | float | The max compatible version of jitran |
--- //= Every |
| version | float | The version of the language |
1.0 |
| homepage | String | The URL of the homepage of the language |
--- |
| repository | String | The URL of the github repository of the language |
--- |
| forum_url | String | The URL of the forum |
--- |
Semantics
The Manifest must defined before the transformation stage.
3.2 Manifest (File)
3.2.o Overview
Overview
The Manifest file contains the manifest data of the language module.
3.2.1 Filename (Semantics)
3.2.2 Syntax
Structure
A metadata consists on an metadata-tag followed by an colon and a value (<tag>:<value>).
Values
Every tag is assigned to a value.
Values (Semantics)
- A boolean must writen in lower case.
- A boolean has two states writen
true(comparable with yes) andfalse(comparable with false). - A string must start and end with an
"(dopple quode) or'(quode). - A string may use escape sequences.
- An integer must writen as an single decimal number.
- A float must starts with a decimal number the integer part.
- A float must ends with a decimal number the float part after a
.(dot). - A float with a float part with value
0may omit the float part and the.(dot).
Metadata Tag
| Tag | Field | Value Type | Discription | Default Value(--- = must not defined, *** = must defined) |
|---|---|---|---|---|
| id | id | String | The id-name |
*** |
| extension | extension | String | The file extension |
*** |
| default-backend | default_backend | String | The id of the default language tranlated to |
--- |
| author | author | String | The author |
--- |
| release-date | release_date | String | The release date |
Current date (Time of compilation) |
| description | description | String | The description |
--- |
| line-comment | line_comment | String | The Linecomment |
--- |
| ignore-linebreak | ignore_linebreak | boolean | If true the lexer do not generate linebreak tokens |
true |
| case-sensitive | case_sensitive | boolean | If true the parse not irgnore individual cases |
true |
| re-declineble-methods | re_declineble_methods | boolean | If true the language support redeclineble methods |
false |
| supported-backends | supported_backends | List<String> | Contains all supported backend language ids |
{} //= Every language |
| key-words | key_words | List<String> | keywords which represent the language. If a keyword represent an other language you can write |
{} |
| block-comment-start | block_comment_start | String | The token that represent the start of an blockcomment |
--- |
| block-comment-end | block_comment_end | String | The token that represent the end of an blockcomment |
--- |
| stdlib-version | stdlib_version | float | The max compatible version of the virtual standard library |
--- //= Every |
| transpiler-version | transpiler_version | float | The max compatible version of jitran |
--- //= Every |
| version | version | float | The version of the language |
1.0 |
| homepage | homepage | String | The URL of the homepage of the language |
--- |
| repository | repository | String | The URL of the github repository of the language |
--- |
| forum-url | forum_url | String | The URL of the forum |
--- |