[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: felix . winkelmann
Subject: Re: What are the long-term goals for R7RS in Chicken?
Date: Sun, 18 Jul 2021 21:10:38 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]