Opened 4 months ago

Last modified 4 months ago

#1463 new enhancement

(use foo) depends on rigid conventions that can and should be relaxed

Reported by: johnwcowan Owned by:
Priority: minor Milestone: someday
Component: core libraries Version: 5.0
Keywords: Cc:
Estimated difficulty: medium

Description

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".

Change History (2)

comment:1 Changed 4 months ago by felix

  • Component changed from unknown to core libraries
  • Estimated difficulty changed from easy to medium
  • Priority changed from major to minor

comment:2 Changed 4 months ago by evhan

This filename loading change could be done, but should it? We already name the file to be loaded, sans extension, in import libraries. This is just not something the user can control at present, and the behaviour for dynamic libraries is to simply use the name of the module. That's a convention we've always used, and it's a nice, simplifying one.

Note: See TracTickets for help on using tickets.