John Cowan
2018-05-20 14:18:46 UTC
(I'm not sure which mailing list to post this to, so I'm using guile-user
as seemingly the most general.)
As an R6RS implementation, it would improve interoperability if Guile
accepted .sls and .guile.sls as extensions for module files. In this way,
it would be possible to release portable code with wrapper files making it
into a module for various R6RS or indeed non-R6RS Schemes. Though these
extensions are not dictated by the R6RS itself, they are very widely
adopted conventions among R6RS implementations. In general, a foo.sls file
is expected to contain a portable R6RS library, whereas a foo.<impl>.sls
file wlil contain an R6RS library that uses <impl>-specific features.
The Right Thing is probably to simply add them to the primitive-load
function, which currently searches only for files named foo.scm and foo. I
see no need to insist that foo.sls or foo.guile.sls contain only R6RS
library forms as opposed to Guile modules.
as seemingly the most general.)
As an R6RS implementation, it would improve interoperability if Guile
accepted .sls and .guile.sls as extensions for module files. In this way,
it would be possible to release portable code with wrapper files making it
into a module for various R6RS or indeed non-R6RS Schemes. Though these
extensions are not dictated by the R6RS itself, they are very widely
adopted conventions among R6RS implementations. In general, a foo.sls file
is expected to contain a portable R6RS library, whereas a foo.<impl>.sls
file wlil contain an R6RS library that uses <impl>-specific features.
The Right Thing is probably to simply add them to the primitive-load
function, which currently searches only for files named foo.scm and foo. I
see no need to insist that foo.sls or foo.guile.sls contain only R6RS
library forms as opposed to Guile modules.