🚀 go-pugleaf

The use of "conversions" and "casts" in Turing follow a similar philosophy
to that in Modula 2, but with different terminology and syntax.  Perhaps
the way this is done may be of interest to the ongoing discussion of
Modula 2's methods.

In Turing there are "type transfer functions", for example, strint("11")
transfers (converts) the string "11" to the int (integer) 11.  There is
a complete set of these functions (for predefined types) built in to 
the language, eg, intstr, realstr, etc.  These are, incidently, used as
the basis for defining input/output statements, which implicitly convert
internal values to strings and vice versa.  These are mathematically
defined, ie, are machine independent.

In Turing Plus (but not in the clean subset, Turing proper), there
are also "type cheats", which you may want to call "casts".
These take one value and consider its representation to be a value of
another type; for example, type (char, i) takes value i (perhaps a one
byte integer) and considers it to be a character, without any generation
of code or change of the bits (no change of representation).  These
"type cheats" are inherently dirty (implementation dependent); that's
why Turing proper (a mathematically defined language) avoids them,
but Turing Plus (which supports systems programming) includes them.

Turing Plus includes a "short form" # for one of the common uses of type 
cheats, which is the case in which you want to "neutralize" or "naturalize"
a value so as to interpret as an unsigned number.  For example, # c,
where c is a char variable, considers the value to be an unsigned number.
This is equivalent to the longer form: type ( nat1, c ) in other words
# c is short for type cheating c to a one byte natural (unsigned) number.