From: Alex Mizrahi
Subject: symbols
Date: 
Message-ID: <bilvd1$b2geq$1@ID-177567.news.uni-berlin.de>
Hello, All!

how symbols are internally handled by lisp?

if i do

(setq l (list 'a 'b 'c))

what will cars point on? strings, some internal structures?

if i do such function

(defun foo ()
    (setq *bar* 1))

and compile it to fasl, how will it be binded to actuall *bar* global var on
load?


With best regards, Alex Mizrahi.

From: Barry Margolin
Subject: Re: symbols
Date: 
Message-ID: <yAv3b.487$mD.97@news.level3.com>
In article <··············@ID-177567.news.uni-berlin.de>,
Alex Mizrahi <····@etel.dn.ua> wrote:
>Hello, All!
>
>how symbols are internally handled by lisp?
>
>if i do
>
>(setq l (list 'a 'b 'c))
>
>what will cars point on? strings, some internal structures?

Typically they will point to internal structures that represent the
symbols.  The implementation might be something like the following C
declaration:

struct symbol {
  char *pname;
  lispobj_t value_cell;
  lispobj_t function_cell;
  lispobj_t home_package;
  lispobj_t property_list;
};

>if i do such function
>
>(defun foo ()
>    (setq *bar* 1))
>
>and compile it to fasl, how will it be binded to actuall *bar* global var on
>load?

The FASL file will probably contain a table that lists all the symbols that
are used anywhere in it, and the code for the function FOO will contain a
placeholder that refers to the entry in that table for *BAR*.  When the
file is being loaded, Lisp goes through the symbol table and finds all the
symbols (creating them if necessary), and replaces the placeholders with
pointers to the actual symbols.

This is similar to the way a link editor works with exported functions and
variables in a language like C.

-- 
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Frode Vatvedt Fjeld
Subject: Re: symbols
Date: 
Message-ID: <2hvfshl7s1.fsf@vserver.cs.uit.no>
"Alex Mizrahi" <····@etel.dn.ua> writes:

> how symbols are internally handled by lisp?

They are a native data-type, represented by some data structure.

> if i do
>
> (setq l (list 'a 'b 'c))
>
> what will cars point on? strings, some internal structures?

  (mapcar #'type-of l) => (symbol symbol symbol)

That is, the cars will point to some data structure, which typically
each hold a slot for the symbols' value, its function-value, its home
package, the plist, and the name (a string).

> if i do such function
>
> (defun foo ()
>     (setq *bar* 1))
>
> and compile it to fasl, how will it be binded to actuall *bar*
> global var on load?

Probably much the same way that the function intern looks up a symbol
based on some string, locating (or creating) the symbol with that
string as its name. The exact nature of this aspect of fasl loading is
of course implementation-dependent, since the whole point of fasl
files is to enable fast(er) loading of files by taking advantage of
implementation specifics. But quite likely, sometime during the fasl
loading, the call (intern "*BAR*") or something equivalent will
happen, just as it would during the loading of a textual lisp file
with this content. Conceptually, it's much like the dynamic linking
process of C systems.

-- 
Frode Vatvedt Fjeld