Hi Jon,

> In the docs at <http://www.software-lab.de/doc/ref.html#symbol> I read
> that "The CDR of a symbol cell is also called VAL, and the CAR points to
> the symbol's tail”, but in the Ersatz code (built from fun.src) I see
> this ...


>    final static class Symbol extends Any {
>       Object Obj;
>       Any Prop[];
>       String Name;
>       Symbol(Any val, String nm) {
>          Car = val == null? this : val;
>          Name = nm;
>       }
> … and here it seems to me that you store the Symbol’s value in the ‘Car’.

Correct. ErsatzLisp cannot use that very efficient two-pointer cell
structure, because Java doesn't have pointers! :(

Instead, the cell structure must be emulated in an object. This is
unfortuate, because instead of 8 bytes (on a 32-byte system), a symbol
in ErsatzLisp needs 44 bytes (iirc).

> Can you explain why it is CDR==VAL in the docs, but "Car = val”
> (instead of "Cdr = val”) in Ersatz?

This is not so wrong as it might look ;-)

The description above is about the _cell_ structure of a symbol

      |  |  | VAL |
         | tail

BUT the behavior of the function 'car' is different: It is just a
pointer-dereference! It takes the value where a pointer points to.

In case of a (list) cell

      | CAR | CDR |

the pointer points to the first _half_ of the cell, and dereferencing it
gives the 'CAR' value.

But if you look at the diagram of the symbol above, you see that the pointer
points to the _second_ half of the cell, yielding the 'VAL'.

If you look at the doc of 'car', you see

   (car 'var) -> any

telling us that 'car' accepts a 'var' (which is either a symbol or a cell), 
the function 'cdr'

   (cdr 'lst) -> any

only accepts a 'lst' (either NIL or a cell).

So the function 'car' can be applied to both a symbol or a list cell,
and will return a meaningful value, while 'cdr' can't do that (as also
follows from the 'Symbol' diagram above: Applying 'cdr' to a symbol
would return the CAR of the _next_ cell in memory, giving meaningless

(car 'Sym) is equivalent to (val 'Sym).

All that behavior is a result of the pointer tag systematics of

♪♫ Alex
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to