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]

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


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

> > 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.
> 
> Hmm, have I misread R5RS?
> 
> I thought the whole point of (interaction-environment) was that it
> returned exactly the environment you were interacting with --- the
> definitions you typed at the repl are here, etc.  So it corresponds
> exactly to what we want here.

It is stated in the report that redefining built-in procedures is
allowed, and that this shouldn't affect the behaviour of other
built-in procedures.  R5RS also allows for the null-environment and
scheme-report-environment to be immutable.  So problem 3 is solved for
the scheme-report-environment.

Here's the entry about the interaction-environent:

 - optional procedure: interaction-environment
     This procedure returns a specifier for the environment that
     contains implementation-defined bindings, typically a superset of
     those listed in the report.  The intent is that this procedure
     will return the environment in which the implementation would
     evaluate expressions dynamically typed by the user.

It reads "*the* environment that contains *implementation-defined*
bindings, typically a *superset* of those listed in the report".

This is why I said it is talking about problem 2---it is talking about
which bindings should be supplied in the environment of the repl.

But since *the* interaction-environent is mutable, the user can
redefine it's bindings.  Due to the requirement about redefined
built-ins, a strict interpretation then yields that other built-ins
can't be allowed to depend on implementation-defined bindings.  This
is silly and this is why I said (after having read only the
interaction-environment entry, BTW) that R5RS doesn't address problem
3.

But I agree that the report is obviously intending that the
environment returned by (interaction-environment) is the environment
where the user creates his own bindings.

/mdj