[Chicken-janitors] #1463: (use foo) depends on rigid conventions that can and should be relaxed

[Chicken Trac]

#1463: (use foo) depends on rigid conventions that can and should be relaxed
-------------------------+--------------------------------
 Reporter:  johnwcowan   |                 Owner:
     Type:  enhancement  |                Status:  new
 Priority:  major        |             Milestone:  someday
Component:  unknown      |               Version:  5.0
 Keywords:               |  Estimated difficulty:  easy
-------------------------+--------------------------------
 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".

--
Ticket URL: <https://bugs.call-cc.org/ticket/1463>
CHICKEN Scheme <https://www.call-cc.org/>
CHICKEN Scheme is a compiler for the Scheme programming language.