# SLang IR (v0.2)

## Parser AST structure

### Notation

_Italic_ - abstract class
Subtree - derived classes

### Actual structure

- _ENTITY_
- IDENTIFIER
- COMPILATION
- USE
- PARENT
- _TYPE_
- UNIT_REF
- MULTI_TYPE
- RANGE_TYPE
- TUPLE_TYPE
- ROUTINE_TYPE
- _DECLARATION_
- VARIABLE
- ROUTINE
- INITIALIZER
- UNIT
- PACKAGE
- CONSTANT
- FORMAL_GENERIC
- FORMAL_TYPE
- FORMAL_NONTYPE
- _STATEMENT_
- BODY
- IF
- STMT_IF_THEN
- CHECK
- RAISE
- RETURN
- BREAK
- ASSIGNMENT
- LOOP
- TRY
- CATCH
- _EXPRESSION_
- COND_IF_THEN
- _PRIMARY_
- CONDITIONAL
- THIS
- RETURN_EXPR
- OLD
- REFERENCE
- UNRESOLVED
- LITERAL
- TUPLE_EXPR
- SECONDARY
- MEMBER
- CALL
- UNARY
- NEW
- IN_EXPRESSION
- BINARY
- POWER
- MULTIPLICATIVE
- ADDITIVE
- RELATIONAL
- LOGICAL

## IR description

### General

**SLang IR** -- text in UTF-8 encoding in JSON format (conforming to the [ECMA-404](https://www.ecma-international.org/publications/standards/Ecma-404.htm) standard) that contains the semantic information about entities of some compilation unit previously parsed and analyzed by SLang compiler frontend. This text should also conform to the specification given below (to the extend that is currently supported by SLang compiler frontend).

If SLang IR is stored as a file in some file system, the preferred extension for such file's name is `.slangir`. If considered filesystem is capable only of dealing with filename extension of length 3 (excluding the separating full stop character), then `.sir` may be chosen as the filename extension.

Some of the terms used next in this document refer to the ones used in _ECMA-404_.

A _JSON text_ that pretends to contain SLang IR should be a _JSON value_ that represents [Compilation](#Compilation) as described below (may be refered next as _SLang module_).

Some _object_ values may have a restricted set of names for _name/value pairs_, while others may contain _values_ of similar type with different _name_ per each one. The ordering of pairs in any _object_ is unspecified, while in every _array_ ordering should be taken into account.

### IR structure

#### Compilation

It is an _object_ having the following name/value pairs (the same format of object content description will be used for some other entities):

- `name`: _string_, name of the _SLang module_;
- `types`: see [Types](#Types);
- `routines`: see [Routines](#Routines).

#### Types

_Object_, each value of which is a [Type](#Type) having the corresponding unique name in current _SLang module_.

#### Type

_Object_ with following name/value pairs:

- `kind`: _String_, one of:
- [`unit`](#Type-unit).

Other fields depend on the value corresponding to the name `kind`.

##### Type `unit`

- TODO

#### Routines

_Object_, each value of which is a [Routine](#Routine) having the corresponding unique name in current _SLang module_.

#### Routine

_Object_ with following name/value pairs:

- TODO