> The convention (observed at least by Chibi, Gambit, and Gauche) is that > each .sld file contains one define-library form. > > Gambit can compile something like hello.sld: > > (define-library (hello) > (import (scheme base)) > (begin (write-string "Hello world\n"))) > > into an object file hello.o1 via "gsc hello.sld". The gsi interpreter > can load either the original hello.sld or the compiled hello.o1. (I'm > not sure why it appends a running number to the ".o" suffix.) The same > arrangement would probably work for Chicken.
I think you can do the in Chicken as well, or I may misunderstand the implications ehre. > The code to implement simple libraries is often written directly into > the .sld file itself. Complex libraries tend to have the implementation > parcelled out into one or more separate .scm files, which are (include > "...") from the .sld file. Non-portable files may be included via > cond-expand. Looks easy enough to do. > > (include "...") must always specify the file name extension of the file > being included, though in practice that tends to always be ".scm". The > file foo/bar.sld files is imported via (import (foo bar)) and the import > never specifies the file name extension; ".sld" is implied, though > something else could be used as well; R6RS tends to use ".sls". But I"d like to stress the fact that run-time and compile-time file locations may differ, also things like dynamic loading vs static linking come into play. In the end this is a build issue, not necessarily a question of run-time semantics. Actually, the physical locations of code are secondary, as long as libraries are found, resolved and evaluated properly. Once again, I can not help but point towards "csm"[1], as a natural and convenient (yet, apparently sadly ignored), tool-based solution to this problem. cheers, felix [1] http://api.call-cc.org/5/doc/csm
