#214 require-library makes modules available in wrong environment

[Norman Gray]

When REQUIRE-LIBRARY is evaluated within an environment
obtained from SISC-INITIAL-ENVIRONMENT, the included
module is made available within the top-level environment,
and not within the new environment. See the code below.

Scott Miller's analysis: I've tracked the bug down to eval,
which compiles expressions in the custom environment,
but doesn't execute them in that custom environment.
Ordinarily that doesn't matter, since free references are
compiled to point to the right env. But for load, which
defines into the current environment, it does. I'm just
verifying that the fix doesn't break anything, and then
I'll check into the 1.16 branch.
<https://sourceforge.net/mailarchive/forum.php?thread_id=31575017&forum_id=7422>

% cat m.scm
(module m
(mval)
(define mval 1))
% CLASSPATH=$PWD sisc
SISC (1.16.0-alpha)
#;> (import m) ; should fail -- OK
Error: import from unknown module m
---------------------------
To enable more detailed stack tracing, set the dynamic parameter max-stack-trace-depth to a non-zero value, e.g. 16.
---------------------------
Some stack trace entries may have been suppressed. To see all entries set the dynamic parameter suppressed-stack-trace-source-kinds to '().
#;> (define (eval-list el)
(let ((env (sisc-initial-environment)))
(let loop ((l el))
(or (null? l)
(let ()
(eval (car l) env)
(loop (cdr l)))))))
#;> (eval-list '((require-library 'm)
(import m)
(display mval)
(newline)))
Error: import from unknown module m
console:7:13: <indeterminate call>
#;> mval ; should fail -- OK
Error: undefined variable 'mval'.
#;> (import m) ; should fail -- but doesn't
#;> mval
1
#;>

[Scott G. Miller]

Logged In: YES
user_id=25869
Originator: NO

Fixed.