Hi!

I assume that most users of Gambit will not do a full code review of the more than half a million lines of code before using it on their computer. So it is a fair guess that they implicitly trust that the code they got on the github.com/gambit account does not contain malicious code (by the way thank you for trusting the Gambit maintainers, currently only Brad Lucier and myself!). The code that might be automatically installed (if one uses the default configure settings) is code from that same account. As I said, this can be turned off in various ways if you are uncomfortable with trusting the Gambit maintainers. This decision can also be taken by the maintainers of the "gambit" package for your OS when they write their package build script.

Concerning your module example there are a few problems with your code.

Firstly, in main.scm you are doing a (import (maintest worker)) so the Gambit runtime system expects to find this module in the default module search order directories which are ~~lib, the Gambit installation lib directory that contains builtin modules, and ~~userlib, that usually maps to ~/.gambit_userlib. Here there are several options. You could install your (maintest worker) module in ~/.gambit_userlib (please read the manual to see how to do this with the gsi -install command). For development, an interesting option is to add the CWD to the module search order, by adding . on the gsi command line or by using the runtime option search=. (either on the gsi command line or in the GAMBOPT environment variable). For your specific example you could do GAMBOPT=search=. ./main.scm or use the shebang line #!/usr/bin/env gsi-script -:search=. or #!/usr/bin/env gsi-script .. It would be very wrong for Gambit (or any Scheme system) to always assume that the interpreter can search for modules in the CWD as this might execute the wrong (malicious?) code if you have done cd somewhere/else ; ../../main.scm. If you want the Gambit runtime system to find the modules in the mods subdirectory next to a compiled executable program you can also set search=~~execdir/mods. There is currently no ~~scriptdir however to locate modules relative to a script, but this might be a future addition to Gambit if there's a need.

The second problem is that the imported module's name, (maintest worker), indicates that this is a module whose source code is stored inside a directory named maintest in one of the module search order directories. You have the option of storing the worker.scm file in maintest/worker/worker.scm (the preferred place) or in maintest/worker.scm. So to fix the issue you need to mkdir maintest ; mv worker.scm maintest and execute GAMBOPT=search=. ./main.scm or any of the other options in the previous paragraph or simply gsi . main.scm, which is what I typically use during development. The . on the command line is a reminder that the modules being used by the program are not just the installed modules (so an installation step will be required when the code goes into production).

If you encounter this situation again (module not found), you can turn on a debug flag that will trace the steps of the module search algorithm like this: gsi -e '(##debug-modules?-set! #t)' main.scm. I'm considering a more concise command line option to do the same.