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: > R5RS talks about the interaction environment; the exact name escapes > me, but it seems like they're addressing the same issue, so we could > borrow the naming convention with them. That way, there will be no > surprises when we implement R5RS. Note that we have three partly separate problems here: 1. How to generally group bindings into suitable modules and how to name these properly. Here the main concern is to get a natural hierarchy of modules which is intended for general purpose use. 2. How to group bindings into "kitchen sink" modules tailored for particular common uses, e.g. the guile-repl module, and how to name them. 3. How to protect the user from modifying builtin bindings in a way that affects other parts of the system. I'm currently mainly concerned with problem 3. The solution to 3 currently requires us to place the user in a "null" environment and then copy bindings from the root module. The R5RS doesn't address problem 3. R5RS' interaction-environment is a problem 2 environment. Except for the bindings it imports and re-exports from the scheme-report-environment, it defines it's own "implementation-defined" bindings. If the user would redefine these, he would influence the interaction-environment as seen by others as well. So, the module which the user starts in, which is currently called "(guile-user)", should not be named "(interaction-environment)" but should copy bindings from the interaction-environment. I'm not saying that "(guile-user)" is a good name, however. To select a good name probably requires thorough thinking about how the future Guile module hierarchy should look like and how the problems 1-3 are to be solved. /mdj