bits values as unsigned quantities

Algol 68 integral values are always signed. As such, the integral modes short int, int, long int etc, and the arithmetical, relational and other operations defined on them all assume signed quantities.

This, by itself, and assuming enough precision in the underlying machine representation of the quantities, is not a problem, because the domain of signed numbers covers the domain of non-negative numbers, so in principle there is no need to provide a mode just for non-negative numbers. On the contrary, using the same mode avoid unnecessary conversions in many cases, and leads to a more general language with less concepts and less rules. It is an useful feature.

However, once we step out of the immanency of the language and start communicating with the outside world, be it via transput or via procedure calls, the absence of unsigned integral values and modes becomes an actual problem, as it is not possible to cover the domain of an unsigned integral mode with an Algol 68 integral mode of the same precision (measured in number of bits, for example) because the later is signed. We are then forced to use a higher precision signed integral on the Algol 68 side to accommodate an unsigned value with lower precision on the other side, and since the precision has an impact on the interface (higher precision means more storage and possibly even different means of passing arguments) it becomes difficult, if not impossible, to use the foreign interfaces as such in these situations.

For example, suppose we want to call a function defined in C as void frob (unsigned int n). If we are using the GCC Algol 68 compiler, we now that the precision of a C unsigned int is the same than the precision of an Algol 68 int, so we could wrap the C function using a formal hole proc(int)void myfrob = nest C "frob". However, the Algol 68 int parameter does not cover the entire domain of the C unsigned int parameter: it is not possible to, for example, pass max_int+1. Changing the formal hole so an Algol 68 long int is used to pass the parameter does not fix the problem, as it very likely breaks the interface.

The Algol 68 standard modes SIZETY bits were originally intended in order to efficiently transport the different constituent bits of integral values, understood as truth values, and to operate on them with logical operations. To ease this, the language guarantees that the precision of any given SIZETY bits mode is be the same than the precision of the corresponding SIZETY int. It is therefore possible to convey integral values in bits values.

A common technique is therefore to use bits values in order to convey unsigned quantities achieving the precision expected externally. In the above example, we would interface the external frob with something like proc(bits)void myfrob = nest C "frob";.

Decimal radix in bits denotations

The set of allowed radices in bits denotations are 2, 4, 8 and 16. This is explicit in the Algol 68 grammar, and it clearly reflects the intention of bits values to be used to convey bits and to operate on them: all these radices correspond to numeric bases (binary, octal, hexadecimal, ...) which are often used in contexts in which the bits structure of the denoted quantities should be easily recognizable. In this domain the decimal base is not very useful.

However, as we have seen, it is common to use bits values to convey unsigned integral values that fit in some given precision (number of bits) eases interfacing with programs written in other languages that support unsigned integral modes. In these cases, using decimal might be most natural.

This extension allows to specify SIZETY bits denotations in decimal by using the radix 10r, such as in short short bits top = 10r255.