Re: the default script environment

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

Jim Blandy <jimb@red-bean.com> writes:

> 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.

To me, your arguments for alternative 2 seems stronger.  I vote for
this alternative (that the REPL environment should be different from
the script environment and that the script environment should be
slim).

One of the stronger arguments is portability: It should be possible to
use a Guile script in any environment, regardless of what .guile says.

> 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.

(Just FYI: I've implemented this already.)

> 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.

I agree.  .guile should describe the user's modifications of the REPL
environment.

> 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.

There might be a way to have the cake and eat it too: For example, we
could copy the behaviour of the great shells:

Introduce an environment variable GUILE_ENV.  When Guile is started
non-interactively, it checks if this exists.  In that case it loads
the file $GUILE_ENV.  Unlike the shell behaviour, I think this file
should be loaded also during interactive use, before .guile.

Maybe the strongest argument for alternative 2 is that the long
experience of shell usage has converged upon a situation where the
interactive environment is different from the batch one.  Since Guile
is going to be used in similar situations, we should do the same.

/mdj