Re: What are the long-term goals for R7RS in Chicken?

[felix . winkelmann]

> 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