the default script environment

[Jim Blandy <jimb@red-bean.com>]

Based on a recent discussion on the bug-guile mailing list, I'd like
to present two ideas, and hear people's arguments for and against.

First idea:

When Guile interprets a script, it should give the script the same
initial environment as you see by default when you run Guile
interactively (using the read-eval-print loop, or REPL).  (Currently,
the interactive environment imports some additional modules, for the
user's convenience.)

- This change would make it easier and less confusing to debug
  scripts, since you could start up Guile and see the same world your
  script sees.
- Importing the additional modules makes interactive startup slower,
  whether you use the bindings or not.
- If the user generally wants those modules available, she should be
  able to put (use-module) forms in her ~/.guile script.


Second idea:

When invoked as a script interpreter, Guile should not load any site
or user customization scripts.

- If such customization scripts load files or change definitions, they
  affect the environment the main script sees.  This makes it unreliable
  to use scripts from the net, because the script author tests their
  script in a different environment from the one you run it in.
  Script authors might also put definitions or imports in their own
  customization files, forget about them, and then accidentaly publish
  scripts that don't work for anyone else.
- If you are writing a script intended only for yourself or your site,
  and you want your customizations, it's easy enough to put one load line
  at the top of your script to load them.  This also makes the
  dependency explicit.
- Sometimes people work around bugs with code in the site or user
  customization files.  This is fine, but those bugs should be fixed
  in the sources and Guile should be re-installed.
- Perl doesn't load site customization scripts, as far as I know,
  probably for this reason.

These two ideas are actually in tension with each other: one says that
scripting and interaction should behave similarly, while the other
says that they should behave differently.  I think that's okay,
though.

Part of the solution is to give Guile a switch which says, "Don't load
any customization files," akin to Emacs's -q switch.  But I still need
to explain why I want the differentiation at all.

The thing is, the REPL exists to serve a particular user, so it makes
sense to give her control over that environment, by loading a
customization file when the REPL starts.

However, a script is something meant to be used many times.  We can
only give the user the misleading illusion of control over the initial
environment a script runs in; she can't actually affect how behaves on
the other systems on which her script might run.