The R5RS has little information on the load operation and R6RS has nothing. The R5RS says nothing about what environment will be affected. I think it is a feature and not a bug. You can call a function that loads a file. The function can use the contents of the file and when the function terminates the cells used within the function to load the external file may be GC'ed. If you want to load a file whose contents need to be available in the global environment you invoke load outside of any defined function which puts the contents in the global environment.
I'm open to discussions as to why the code should be changed to always load files using the global, rather than local, environment.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I hadn't thought of checking the spec... I'll leave the Bug-or-Feature decision to you.
My main argument for the change is SLIB. SLIB assumes that the definitions contained in any file loaded via (load) will end up in global namespace. So, making this change will make TinyScheme's (load) compatible with all the Scheme implementations supported by SLIB (listed here: http://people.csail.mit.edu/jaffer/SLIB).
With this change, it is easy to port SLIB to TinyScheme.
As a worked example, say you wanted to use SLIB's getopt. Your script would have the line:
(require 'getopt)
This would end up calling the SLIB function (slib:load) to load the file containing getopt. (slib:load) would call (slib:load-source), which would call (load). SLIB assumes that getopt is in the global environment is the (load) call succeeds.
Here is a test case. Usage:
./scheme
(load "load_test.scm")
(test-load)
Without the patch, TinyScheme reports that variable "afun" is unbound. With the patch, TinyScheme will print "Success!".
The R5RS has little information on the load operation and R6RS has nothing. The R5RS says nothing about what environment will be affected. I think it is a feature and not a bug. You can call a function that loads a file. The function can use the contents of the file and when the function terminates the cells used within the function to load the external file may be GC'ed. If you want to load a file whose contents need to be available in the global environment you invoke load outside of any defined function which puts the contents in the global environment.
I'm open to discussions as to why the code should be changed to always load files using the global, rather than local, environment.
I hadn't thought of checking the spec... I'll leave the Bug-or-Feature decision to you.
My main argument for the change is SLIB. SLIB assumes that the definitions contained in any file loaded via (load) will end up in global namespace. So, making this change will make TinyScheme's (load) compatible with all the Scheme implementations supported by SLIB (listed here: http://people.csail.mit.edu/jaffer/SLIB).
With this change, it is easy to port SLIB to TinyScheme.
As a worked example, say you wanted to use SLIB's getopt. Your script would have the line:
(require 'getopt)
This would end up calling the SLIB function (slib:load) to load the file containing getopt. (slib:load) would call (slib:load-source), which would call (load). SLIB assumes that getopt is in the global environment is the (load) call succeeds.
You can see the Kawa specific file containting (slib:load) here; http://cvs.savannah.gnu.org/viewvc/slib/slib/kawa.init?view=markup.
Let me know if you have any questions.