Concerning Tables (Tips from Vaporware) - KVonGit/zil-stuff GitHub Wiki

https://archive.textadventures.co.uk/forum/design/topic/miawi_wxbeulill8p-bc-q.html

vaporware

01 Jun 2021, 02:34

Hi! Author of ZILF here with a few notes.

1. PT, as in GETPT and PTSIZE, stands for property table -- i.e., the span of memory that contains the data for a particular property. Whereas <GETP ,OBJ ,P?PROP> returns the value stored in the property, <GETPT ,OBJ ,P?PROP> returns the address where that value is stored, which can then be accessed with table functions like GET.

2. PTSIZE returns the size (in bytes) of a property table whose address was previously obtained with GETPT, by decoding the header stored just before the property data. In practice, it functions as a "TypeOf" for direction properties, because the compiler ensures that each type of exit has a different length when it's stored as a property.

3. MDL has both Lisp-style linked lists, written with (), and vectors (arrays), written with []. Conveniently, they can be accessed with the same functions. To get the nth element of a list or vector, you can use the NTH function (<NTH ,FOO 3>) or simply use a number as a function name (<3 ,FOO>). To iterate through the elements of a list or vector, you can use MAPF (or occasionally MAPR), which is basically a foreach loop that uses a lambda for the loop body and can return a value. But...

4. Code that runs on the Z-machine (i.e. code inside a ROUTINE) doesn't have access to dynamic memory allocation, and therefore doesn't use linked lists. Or lambdas. In fact, none of the dynamic features of MDL are available at runtime: value types are lost during compilation, so there's no way to test whether the value in a variable is a number, a string, an object, or a table. You might still encounter uses of things like MAPF in ZIL code, but they'll be in code that runs at compile time (i.e. MDL). Therefore...

5. ZIL uses TABLE for data that has to be accessible at runtime. A table is a fixed length vector with some special properties; for example, different elements can take up different amounts of space in the table. LEXV is the main example of that: every third element is stored as a word (2 bytes), and the rest are stored as single bytes. That metadata, like everything else about value types, is lost during compilation.

6. If you want to know more about low-level details like this, one way is to compile some code with ZILF and then look at the assembler output (.zap files). There's also Henrik Åsman's ZILF Reference Guide.