This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
load/require semantics - fixing a test-case
- From: Per Bothner <per at bothner dot com>
- To: "kawa at sourceware dot org" <kawa at sourceware dot org>, alex mitchell <alexm at nus dot edu dot sg>
- Date: Thu, 30 Sep 2010 14:14:12 -0700
- Subject: load/require semantics - fixing a test-case
I'm working on some tweaking of the semantics of declarations
in files, including the distinction between load/eval and require.
One goal is to make the semantics of require more consistent.
As a side effect one existing test-case needs to be changed.
The testsuite/test-load-require.scm (based on a bug report from Alex)
will need to have some module-export statements added. The previous
behavior was I believe a bug.
The test case (see the rule check-load-require in testsuite/Makefile)
loads test-load-require.scm and then calls mytest3. The function
mytest3 is defined in test-load-require-3.scm, which is required
by test-load-require-2.scm, which is required by test-load-require-1.scm,
which is required by test-load-require.scm.
The problem is that require imports a set of definitions into the
current lexical scope - but it is not supposed to automatically
re-export those definitions, even if the require happens inside
code that is loaded. The fix is to add explicit exports:
(module-export mytest2 mytest3) ; in test-load-require-2.scm
(module-export mytest1 mytest3) ; in test-load-require-1.scm
This may be a good time to point out the difference between:
$ kawa -f foo.scm
and
$ kawa foo.scm
The latter (without the -f) is supposed to be equivalent to
(require "foo.scm"). It is also supposed to be equivalent to
compiling foo.scm and then immediately running it. The scope
of a declaration in foo.scm is local to the module, unless
the declaration is exported. (If there is no module-exports,
the all top-level declarations are by default exported.)
The former (with the -f) is equivalent to (load "foo.scm").
It reads foo.scm line-by-line, and evaluates each top-level
form before reading the next one, using the dynamic
environment. A module-exports declarations won't make sense.
Most of the time both forms will behave the same: If you
require a module from the interactive command line (or
eval or load) then the module's exported declarations will
be added to the dynamic environment. However, there are
subtle differences, for example in macro-expansion,
or to what extent a variable can be redefined.
--
--Per Bothner
per@bothner.com http://per.bothner.com/