This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Jim Blandy <jimb@red-bean.com> writes: > another environment. So modules have at least two environments they > care about. Okay. But why many /types/ of environments? Environments may play differend roles but essentially they are all the same kind of environment. At the moment I think we need only one environment type (one environment smob) but of course you can create many environments and these environments may play differend roles. I´ve started to implement environments -> ftp://ftp.tfh-berlin.de/pub/incoming/guile-hack.tar.gz If you look at the code (environments[ch], eval.c), you'll see that an environment is a pair that consists of a local environment and a smob: (<environment smob> . <local-alist>). The top level environment is (<environment smob> . EOL). This pair is passed down in `scm_ceval (x, env)' and each time a value has to be looked up, this value will be looked up in the local environment and then in the environment smob. At the moment only the `system global environment' is created, but you could create other environments and put these environments into some kind of data structure. Let's call this data structure a "module". The module has to set the environment's function pointer SCM (*sym2vcell_other_environments) (SCM self, SCM sym, SCM modify) to a method that looks up a sym in all other module's environments and returns its vcell plus the environment where the vcell is interned. I think that's all you need. Everything else can be implemented on scheme level. So at the moment I think we need only one environment type. The functions (*ref) (), (*fold)() etc. can be static functions not dynamic ones. In other words: A module smob has one or more environments and these environments can be manipulated by using the functions you've described. But the module (not the environments) is responsible to look up and modify symbols in "its" (global-, export-, etc.) environments by calling the above functions. Jost