Overview
This document is split into two parts: the interpreter's perspective, and the developer's perspective. The first part tries to describe the structure of the "compiled" code and how it is run by the interpreter. The second part describes the "tools and materials" that are available to the developer.
Interpreter's Perspective
The result of compiling a project is a number of binary files (*.al), each of which represents a routine (so that every routine (or a procedure – you name it) of an application can be accessed directly with a unique URL).
The *.al files consist of operations, data constants, and connections between the operations:
- An operation is basically a function that takes certain number of named arguments, and returns a value. All operations are implemented in the interpreter's operation library, and the *.al files contain only the operation identifiers.
- A data constant is a value of any type (or structure). Data constants are passed as arguments to the operations.
- A connection tells the interpreter, that certain operation is used as an argument of another operation.
The interpreter works by loading the operation network from an *.al file, and executing every task-operation. Task-operations are marked as such in the editor, specifying the execution order as well. Every *.al file should contain at least one task-operation.
When an operation, that is being executed, tries to access one of it's arguments, either the constant is used (if a constant was given), or, following the connection, another operation is executed, and it's result is used.
Developer's Perspective
Although compiling an application results in a number of output files, the developer only has to work with a single source file (*.alp), using Aluminium Constructor. The source can be viewed as an organized collection of data for the compiler. At the top level of this organization there are two independent parts: routine layout, and code layout.
The routine layout is basically a list of routines. It is used by the compiler as the reference for generating *.al files. The code that goes into those files, is taken from the second part.
The code layout, at it's top level, is a collection of name-spaces. A name-space is an isolated container of code (if it can be called so :-)). Each name-space contains a number of code diagrams, and a list of tags (hence the name – tags can be accessed only within the name-space). Code diagrams is where the code is drawn (all diagrams within a name-space are considered as a single diagram, so it's purely up to the developer to choose their number and names).
The code is drawn using the following elements:
- Operation
- Operations represent calls of operations from the library.
- Constant
- Constants yield static data that can be passed as operation arguments.
- Tag Reference
- Any code element (except connections) can be associated with a number of tags. A tag reference represents the items that are tagged with the corresponding tag (see Reference Manual).
- Argument Connection
- An argument connection denotes that the item at it's source is used as an argument for the item at it's target.
The code elements (except connection) can also be associated with routines. This is how the compiler knows which pieces of code belong to which routines.