Some questions

[Lynn Winebarger <owinebar@free-expression.org>]

So, I've been reading guile some more.  I have some questions that
I'm slowly answering myself by reading the source, but might be answered
faster by people already in the know.

   I don't understand the last 3 lines of scm_ilookup:
  if (SCM_ICDRP (iloc))
    return SCM_CDRLOC (er);
  return SCM_CARLOC (SCM_CDR (er));

      I mean, I understand the operations, I just don't understand what the
storage scheme behind the operations is. (What is it?)

     Memoized objects:  what's the deal?  The manual mentions them several
times but never defines them.  The evaluator (in particular lookupcar) seems
to memoize everything for evaluation purposes but memoized objects are 
defined in debug.c which should mean they are for debugging purposes.

    I'm catting on a "roadmap" file I've jotted down that might be useful to 
others who haven't looked at the source or are scared off by it.  Please
correct anything I've got wrong.  Yes, they're absolutely 
implementation-specific and would require keeping in sync with the sources.
Maybe some others have something to add they might have found useful
when starting to read the code.

Lynn

----------------------------------
You are on long and twisty path through the forest.
Some useful files:
guile.c   main and inner_main
init.c    scm_{boot,init}_guile1? and scm_load_startup_files
script.c  scm_shell
tags.h    Possible the most important documentation-wise, 
          partially explains the
          convoluted typing scheme and how some immediates
          are actually considered "instructions" for the 
          evaluator, and some notes on how the contents of
          cells are tagged and set up for garbage collection.
gc_os_dep.c   All kinds of hairy details, including the clever
              methods for finding the stack base when scm_boot_guile
              isn't used.
eval.h     home of the iloc macros.  Supposing the i somehow stands
           for immediate, but not clear why it should be named that
           way.  When closures are memoized (translated into the 
           tree code using the goodies from tags.h), the variable
           references get changed into pairs of numbers denoting how
           many "stack" frames up to go, and the offset in the frame
           of the variable (this is set up on the first evaluation
           of the closure).  Actually pair is not right, the frame
           and offset #'s are encoded into one immediate, with the
           lowest 8 bits being a type tag, then (currently)
           11 bits for the frame and some bits for the offset.
eval.c     of course
modules.c  eval really depends on this, as everything depends on
           the (dynamically scoped) module to provide a top-level
           environment.
dynamic-root.c   Adds an odd spicy flavor to guile.  For fluids,
           call/cc tricks, and threads.
debug.[ch]  home of the memoized type.

Booting up a command line guile follows roughly
this sequence (for our purposes there's no returning from the
unindented functions).
main (duh)
scm_boot_guile   (sets up local variable for stack base) 
scm_boot_guile1  
  => scm_init_guile1  inits all the smobs - this is where all
                      those #include "something.x" statements
                      will actually come into play.  Does other
                      initializations as well.
                      Last act is to load startup files, particularly
                      ice-9/boot-9.scm.  boot-9 defines top-repl
                      (using scm-style-repl and error-catching-repl)
                      last act of boot-9 is to set the "current module"
                      to (guile-user)
inner_main  
scm_shell
   => scm_compile_shell_switches  notable in that it constructs the
                           code guile executes.  In particular, it
                           inserts a call to top-repl if guile's invoked
                           for interactive use. returns the expression
   => scm_current_module   (this was set when loading startup files, 
                            remember?). returns the module
scm_eval_x   scm_compile_shell_switches provides the expression, 
             scm_current_module provides the current module (a smob!)
scm_inner_eval_x   this is wrapped by a dynamic wind that sets the
               current module to be the module handed to scm_eval_x 
               on entrance and restores it on exit (redundant in this
               usage).
scm_primitive_eval_x  applies the module transformer (if any) on the 
                      expression, produces a top-level environment
                      consisting of a list with the current module's
                      "eval-closure" (a smob type created in module.c),
                      and then passes the expression and environment off
                      to the real eval (well, scm_i_eval_x, but that just
                      calls the real eval)

---------

eval.c and probably some other files include themselves in
order to produce separate debugging versions of functions
in the object code without having separate versions in the
source.  

*.x files included in init functions are generated by guile-snarf
based on SCM_DEFINE and other macros (which appear all over the code).

lexical environments are just lists of lists of cons cells, but there's
some slight weirdness with the value (may be the cdr or the cadr of the
cons cell).

ilocs: see above at eval.h  some related functions are actually in
       debug.c

memoized smobs:  defined in debug.c  Not clear what is going on here.
     All expressions should get "memoized" as part of expansion/evaluation,
     but the memoized objects appear geared toward preserving the source
     for debugging purposes ??? (otherwise, why is it in debug.c?)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel