NIL is not a symbol

[emmorais]

Here NIL is treated as a symbol, but actually NIL currently has its own expression tag. It could be clearer to make NIL also a symbol, such that it has expression tag equal to Sym. This change is also relevant for LDON representation.

[johnchandlerburnham]

Yes, currently the NIL representation is a little confusing. IMO there are three options:

1. nil as a primitive expression: Tag::Nil + <any hash>
2. nil as a symbol: Tag::Sym + <hash of symbol ".LURK.NIL">
3. nil as a cons-default: Tag::Cons + F::zero()

My preference is for option 3, since that aligns nil with strnil and symnil (the symbol root), but if there are language level or evaluation reasons to do 2, I can adapt the LDON representation to support that. That requires hardcoding the symbol hash of NIL (and possibly some notion of packages) in the serialization, which feels a little inelegant, but wouldn't be hard.

[porcuquine]

We will make NIL have type Sym, with the expected hash value if it were an ordinary Lurk symbol. All NIL checks will then need to become normal pointer equality checks (of both tag and hash).

However, this won't (and shouldn't) happen until 1.0 beta.

[arthurpaulino]

How are nil checks performed in the circuit? Is it done with some hardcoded value for the hash?

[huitseeker]

@johnchandlerburnham @arthurpaulino is this closed by #364 ?

[arthurpaulino]

No, we're still using ExprTag::Nil

[porcuquine]

This is paused without having been changed yet. There is a new candidate plan, which involves making nil and t both have type Bool, with values 0 and 1 — to maximize clarity and efficiency in circuits.