Re: Testing dangerous change in tomorrow's snapshot (was: Re: Guile segv)

[Mikael Djurfeldt <mdj@nada.kth.se>]

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