Hi Jon,
> Thanks for the useful information! And thanks for using Sunday mornings
> for things that matters. ;-)
No Problem. Sunday morning is an ideal time for that :-)
So let me explain a little more, because I think this is a central issue
in PicoLisp:
NIL is a very fundamental piece of data. It has a dual nature, being
both a symbol _and_ a cell of the form (NIL . NIL). From the beginning,
this has been a basic design requirement of PicoLisp.
If you recall from "doc64/structures" (similar also in
"doc/structures"):
NIL: /
|
V
+-----+-----+-----+-----+
|'LIN'| / | / | / |
+-----+--+--+-----+-----+
Physically, the pointer to NIL (shown with the 'V' in the above diagram)
is a true symbol, as it points at an offset of a pointer size into the
memory heap. Taken as such, 'NIL' is a normal symbol,
NIL: /
|
V
+-----+-----+
|'LIN'| / |
+-----+--+--+
having a tail with the characters "N", "I" and "L" (the name), and a
value cell which in turn points to NIL (symbolized with the "/").
However, when this pointer is boldly used as a cell pointer (by ignoring
the pointer tags caused by the pointer size offset)
NIL: /
|
V
+-----+-----+
| / | / |
+--+--+-----+
then it is a normal cell, with NIL in its CAR and NIL in its CDR, which
just happens to be misaligned in memory (i.e. at the place of a symbol).
This structure has great advantages. Any proper list (ending with NIL)
becomes sort of "infinite", allowing to take the CDR as often as
possible and still obtain NIL again and again.
Therefore, a function (like the discussed 'list') doesn't need to check
whether it actually received an argument or not. It can simply take the
next argument with CDR from the argument list, and doesn't see any
difference between (list NIL) and (list). This makes interpretation both
simpler and faster.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
