>>>>> "WP" == Walter C Pelissero <firstname.lastname@example.org> writes:
WP> Michael Sperber [Mr. Preprocessor] writes:
>> LOAD loads into INTERACTION-ENVIRONMENT, not into the PROGRAM
>> package. Using LOAD in conjunction with the module system without
>> explicitly specifying which package to load into is bound to get you
>> into trouble.
WP> You are right. The sample code was crippled. Changing the export
WP> declaration to:
WP> (export main (foo :syntax))
WP> solved the problem.
WP> On the other end I don't understand why the compiled version behaved
WP> differently from the interpreted version.
In the first example you use ,in to enter the package PROGRAM, this
makes PROGRAM the INTERACTION-ENVIRONMENT, FOO is accessible there so
everything is alright (check the value of (interaction-environment)
after a ,in command).
In the second example you do not have access to FOO since it is not
exported and you are not within PROGRAM so this failes.
WP> While at this, would you mind to explain how to load in a different
WP> package other than the interaction-environment? Load accepts a second
WP> argument that is supposed to be an environment but, beside the R5RS
WP> environment primitives nothing is documented. So, how do you get the
WP> current package's environment?
The environment argument required by load is a package. With the
procedure GET-PACKAGE from PACKAGE-COMMANDS-INTERNAL you can map a
name symbol to a package:
> ,config (define-structure foo (export bar) (open scheme) (begin (define bar
> ,open package-commands-internal
> (eval 'bar (get-package 'foo))
Load structure foo (y/n)? y