From: Lynn Winebarger Subject: Some questions Date: Thu, 9 May 2002 00:59:22 -0500 To: guile-devel@gnu.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