id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	difficulty
1463	(use foo) depends on rigid conventions that can and should be relaxed	johnwcowan		"Currently, in order for (use foo) to work correctly, the foo module must be in a source file called foo.scm or its compiled form foo.so.  This should be changed so that the source file can have any name.  This allows extensions other than .scm to be used, and also allows more than one module in a file to be independently usable.

For example, some people prefer the extensions .ss or .sch for source code, and the extensions .sls and .sld have been used for files containing modules in other Schemes.  This allows file pairs like foo.sld for the module declaration and foo.sch for the actual variable and syntax definitions.  While Chicken's compiler will compile source with any extension, it preempts the extension .scm for the module itself.  This makes it impossible for a Chicken module (required extension .scm) to coexist in the same SRFI repository with a Guile module (required extension also .scm) that includes the same implementation source file.  I have posted to the guile-user mailing list asking for a similar relaxation in Guile.

Similarly, if the file foobar.scm contains definitions of the modules foo and bar, then neither (use foo) nor (use bar) will work, because they will try to load files named {foo,bar}.{scm,so}, which do not exist.

My proposal to solve this problem is to extend import libraries and ##sys#register-compiled-module to contain the name of the source file as a relative path.  In this way, (use foo) can load foo.import.{scm,so}, which will inform it that the code for the foo module is to be found in foo.ss, or foobar.scm, or wherever it is.  It is then trivial, given the source file name, to compute the shared object file name; just remove the extension and add "".so"".

"	enhancement	closed	minor	someday	core libraries	5.0.0	worksforme			medium