OTIL: The One True Implementation Language

What OTIL is

1. Part of OfflineOS - it is designed to be tightly integrated with the other programming languages and development tools
2. A systems programming language - OTIL is specifically designed for writing the Kernel, dynamic loader and core libraries
3. Procedural and Old-School - The primary influences of OTIL are Pascal (syntax) and C/Cylone (memory-model). Additional ideas have been gleaned from Erlang, Ruby and even Algol.
4. Statically and Strongly typed - Any mixing of datatypes without recasting will result in a compilation error. Unless a Slice is involved.
5. Readable - Aside from integration with the greater OfflineOS toolchain, the greatest distinction between OTIL and its inspirations is the very high "signal-to-noise-ratio" of the syntax.

What OTIL isn't

1. An application programming language - Use MIA instead
2. Easy - Readability is a high priority but that doesn't imply that OTIL code should be easy to write.

Concepts

Toolchain Integration

OTIL is being co-designed with Build, Asm and MIA for smooth, full stack programming.

Multi-language development

While OTIL and MIA belong to very different paradigms they share a common format for modules so that MIA applications can seamlessly call libraries written in OTIL.

Statements vs Expressions

A statement is one step in the program's advancing state.

An expression are either a value, function call or mathematical equation.

In OTIL expressions only act as clauses of statements.

Syntax

See here

Datatypes

See here

Implementation

See here for helpful information if you are looking to design an OTIL compiler.

Best Practises

Embed error conditions in data-structures

Global variables are a common source of bugs, especially in conjunction with multi-threading / multi-processing. Instead of a global error status put an error status field into the definition of a record type.

For example:

CONST input : IO.IOString <- IO.ReadLine(file);

IF status OF input = IO.Okay THEN
    IO.PrintLine{content of input};
ELSE
    IO.PrintLine{"Could not read file"};
END

Don't short-circuit sub-routines

A common bad habit amongst developers is hiding a return or exit statement in an if clause that does not have a corresponding else clause. This is called short-circuiting and can greatly decrease the readability of a program.

Don't use strings directly

As briefly mentioned in the documentation of the string type, it is highly recommended to wrap this type in a record type that provides additional information about it.

This is primarily because of the unreliable nature of 0-terminated strings.

Under Consideration

• Convention that procedures have a final argument that is a reference to an error status
• Find a way of constructing loops that prevents exit conditions from being buried in conditional clauses
• How many varieties of pointers there needs to be
• Whether OTIL needs Cyclone style regions