I just wanted to check on something that I’m observing and documenting. In the ZILF REPL, I have the following:
> <SET Z 10>
10
> <==? .Z 10>
T
> <L? .Z 20>
T
> <G? .Z 50>
#FALSE ()
What I’m checking on here is if this is accurate. Specifically, I’m curious why “T” doesn’t come up as #TRUE ().
Ah, I may have my answer from one of the ZIL guides. Specifically:
So the “T” actually does make sense, it’s more perhaps the FALSE that doesn’t.
I know next to nothing about ZIL, but given its Lispy background… T is probably an atomic type (a symbol with the name ‘T’), while false is the empty list. And if they’re different types it would make some sense that they print differently.
This is answered in the MDL manual.
It’s another one of those things that makes MDL so charming: FALSE is a type, not a value. Every value of the type FALSE is false, and every value of every other type is true. T is used by convention most of the time, but for example when you see ELSE in a COND, that isn’t a keyword - it’s just another true value.
FALSE is a list-based type, and #FALSE () is MDL notation for "it’s the empty list (), but as the type FALSE". You can type that notation into the REPL too. In fact, you can even put values in that list and it’ll still be false, like #FALSE (ERROR CODE 12345) (which hints at how this was meant to be used).
Addendum: so, what is <>? It’s an empty form, which isn’t technically false itself, but it evaluates to a value that is false.
The angle brackets are just syntactic sugar: FORM is a list-based type like FALSE, so <> can also be written #FORM (), <+ 1 2> can also be written #FORM (+ 1 2), etc.
Normally, a form has some elements inside, starting with an atom, and evaluating it means applying a function: we use the bindings of + to find the function to apply, invoke it by passing the 1 and 2 as arguments, and whatever it returns is the value of the form. But when the form is empty, there’s nothing to look up; as a special case, an empty form always evaluates to #FALSE ().