Programming manual (

Data types

On the last page, we saw blocks of {text}, <tags>, numerical values and boolean values, all being assigned to fields inside various tags. How does it all fit together?


Whenever a fresh ioL console window opens — to service a new running program for example — the top-level output the program produces is treated as text. Imagine a big set of invisible curly braces { ... } surrounding your program's entire output, from when your program begins to when it terminates.

This is why, in earlier examples, you could simply output Hello world! from your console and see it displayed almost literally in the ioL console.

$ iol -
ioL: input/output Layer
Copyright © General Development Systems
I am leaving this place. I will not be trapped here! Watch this: }
::ioL::. Invalid syntax: unexpected '}' while reading text at root level

That didn't work. Even after years of training and careful meditation, your program will not be able to escape from the sandboxed environment of input/output reality that ioL has created for it.

Inside a tag, anything surrounded by braces { ... } is treated as a block of text. The very top level (when you aren't inside any tags at all) is also treated as a block of text, but you don't need the braces, since that's the highest level you can go.

Inside a block of text, all characters are accepted and these form part of the text data (some characters, like } need to be entered as escape sequences like </}>).

Tags are also accepted inside blocks of text, even though a tag is not the same as a string of characters. When you put a tag inside a block of text, ioL actually breaks your data up into multiple elements.

The following two fragments of ioL syntax perform exactly the same function in ioL. ioL would treat both lines the same way:

{Here is some text <some-tag-in-the-middle>, and a bit more text.}

{Here is some text }, <some-tag-in-the-middle>, {, and a bit more text.}


We covered tags on the previous page. A tag is syntactically valid inside a block of text as we discussed above, or as an element of data to be assigned to a field inside another tag. In a block of text, tags always need to be enclosed with angle brackets < >. Inside another tag (i.e. when assigning a tag to a field), you can omit the angle brackets if (and only if) the tag has no fields of its own. The following line is yet another valid way to write the example above:

{Here is some text }, some-tag-in-the-middle, {, and a bit more text.}
The tag in the middle had no fields in its definition, so we actually didn't need the angle brackets around it.


Ordinary (decimal) numbers entered into ioL as field values look like you would expect:

1, 7, 3.14, -28

You can also enter numbers in binary (base-2), octal (base-8), or hexadecimal (base-16) notation (this does not affect the way the number is stored within ioL after you enter it):

b10110101.1,   o52,   x10FAA

Hexadecimal notation is particularly useful for entering things like color values and character codes, which are usually listed online in hexadecimal. Note that hexadecimal digits go from 0 to F, and you have to express each (A-F) digit using an uppercase character. Lowercase digit notation is not allowed because certain values could look too much like tag or field names (e.g. xFADE is a valid numerical value written in hexadecimal. xfade is not a valid numerical value; but would be perfectly valid as a tag or field name).

You can also apply an exponent to any value, regardless of your numerical notation. An s followed by a positive or negative decimal value at the end of the number indicates a shift in the position of the point. This shifts the place value of all the digits in your number.

Example Interpretation Result
52s-2 52 × 10-2 0.52
b1011s4 b1011 × 24 b10110000
x19ABCs-2 x19ABC × 16-2 x19A.BC
Caution: ioL uses both integer binary arithmetic and double-precision floating-point binary arithmetic to deal with numbers, depending on the context of the calculation and the machine architecture the ioL console is running on. Some calculations might produce unexpected results. If you were thinking of using ioL in a safety-critical, scientific, or financial application, you would need to be aware of the limitations of binary arithmetic on your target machine's CPU architecture, and the automatic casting behaviour of the ioL console.

Boolean values

true, false

Other literal values

null, inf, invalid

null is used to represent an 'empty' value (i.e. a value has not been assigned)

inf means infinity. It is the result of dividing something by zero.

invalid is the result of an invalid operation. It represents that no valid result is available.

Raw data

Raw, or binary data entry is a special case of text, where the characters are arbitrary, and it is impractical to restrict what kinds of characters are valid to be entered, or to do any kind of text-style processing on the data. For example, data from a JPEG image file: the image data is made up of a series of characters, but most of the information comes from the numerical values of the character codes themselves. These characters are not meant to be viewed on the screen.

To print binary data to an ioL console, you need to know in advance how many bytes of data you are going to send. ioL cannot interpret the characters themselves to know when you are done, since these characters could be anything, so you first must give the exact number of characters in the blob.

[n{ ... }]

n is the literal number of bytes contained in the curly braces.

Raw data is one of the only places where <! comments !> and escape sequences are not valid.


  1. What is the difference in meaning between the following two tag expressions?
    <putln {The value of pi is approximately 3.14}>
    <putln {The value of pi is approximately }, 3.14>
  2. How about these? We want to teach the user how to type the number 10 in binary:
    <span {This is how to type the number 10 in binary: b1010}>
    <span {This is how to type the number 10 in binary: }, b1010>
    Try printing both examples to an ioL console. Does the second example show the user the correct information? Why not?