Language Quirks

Language Quirks

Things the original Blitz3D does that are not obvious, and that BlitzLLVM does the same way because existing programs depend on them. Also see the Language overview.

Order of evaluation

The parts of an expression are not evaluated from left to right. The original labels every part with the number of registers it needs (a number or a variable needs 1, a call or an operation needs more), and evaluates the part that needs more first. Parts that need the same go left to right. This only shows when two parts have side effects, such as Rnd, Rand, Read, a file read or a function that counts, and a lot of old programs depend on it. BlitzLLVM measured and copied it from the original compiler (release build; the original's debug build has extra checks in between and can differ, BlitzLLVM uses the release order in both).

Global count = 0
Function Tick()
	count = count + 1
	Print "Tick " + count
	Return count
End Function
Function Three(a, b, c)
	Print a + "," + b + "," + c
End Function

Three Tick(), Tick(), Tick()
Print Tick() + Tick() * Tick()

Tick 1
Tick 2
Tick 3
3,1,2
Tick 4
Tick 5
Tick 6
26

Arguments of a call

The arguments of functions, commands and userlib functions are taken as a chain: the last two first (the second to last, then the last), then the others from right to left. Optional arguments that were left out count as arguments too.

Arguments	Order	Arguments	Order
1	1	5	4, 5, 3, 2, 1
2	1, 2	6	5, 6, 4, 3, 2, 1
3	2, 3, 1	8	7, 8, 6, 5, 4, 3, 2, 1
4	3, 4, 2, 1	12	11, 12, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1

This is for arguments that are calls. An argument that is a number or a variable has no side effect, so it only decides the order of the others by needing 1 register: F(Rnd(), 5, Rnd()) still evaluates the last Rnd first. An argument that is an expression or a call with several arguments needs more and goes before the simple ones: in F(a(), b() + c() * d(), e()) the second argument is evaluated first, and inside it c() * d() before b().

Operators

The two sides of + - * / Mod ^ And Or Xor Shl Shr Sar, of comparisons, and of a string + follow the same rule: the side that needs more registers first. a() + b() * c() is evaluated as b(), c(), a(), while a() * b() + c() and a() + b() + c() are left to right. A number variable on the left of +, * or an integer comparison is read after the right side was evaluated, so x + F() sees a change that F made to x.

Arrays and stores

The indices of an array with several dimensions are added up as i0 + i1 * size1, so with calls as indices a(F(), G()) evaluates G() first for the same reason. In a store to an array element (a(i) = v), the original evaluates the value or the index first by the same rule: a number is moved to the place after both were evaluated, a string or an object is handed to a function together with it. The sizes of a Dim are evaluated one after the other, left to right.

Left to right

The order of the original is mildly surprising, and no other language does it. To get left to right order for arguments (also of userlib functions), operators, array indices and stores, build with blitzcc --sane-evaluation-order. Programs that call Rnd, Rand or read files several times in one expression then give other results than in the original, so only use it for programs that do not depend on the order.

Strings with Chr$(0)

A string knows its length, so Chr$(0) is a character like any other, as in the original (whose strings are std::string). Len, +, comparison, Left$, Right$, Mid$, Instr, Replace$, Upper$, Lower$, Trim$, LSet$, RSet$, String$, WriteString, ReadString, WriteLine, ReadLine, Print, DebugLog and network messages keep everything after a NUL.

a$ = "ab" + Chr$(0) + "cd"
Print Len(a)          ; 5
Print Instr(a, "cd")  ; 4

A NUL always follows the last character, so a string given to the operating system, a library or a userlib is read as a C string and ends at the first NUL. That includes file names, window titles, Text and the arguments of userlib functions. Strings that a userlib returns end at their first NUL.