[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: Lassi Kortela
Subject: Re: What are the long-term goals for R7RS in Chicken?
Date: Sun, 18 Jul 2021 22:30:54 +0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.12.0

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.

Sorry, I was being ambiguous. The natural strategy when dealing with R7RS is to compile each .sld file [i.e. each (define-library ...) form] into one .o or .so file, traversing any (include "...") files at compile time, not at runtime, so that the code in the included files becomes part of the object code corresponding to the .sld file.

So you'd check foo.sld into git, and compile it and its dependencies into for dynamic linking, or into foo.o for static linking.

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.

I wasn't aware of the tool. Looks like good thinking went into it!

For portable code, the main obstacle in practice is that a different wrapper file is required per each standard and/or implementation. For example, R6RS and R7RS typically require separate .sls and .sld files. (R6RS has many features that are not in R7RS-small, but a lot of useful code would be easily portable if it weren't for the different (library ...) vs (define-library ...) wrappers, as well as the implementation-specific module wrappers in Scheme implementations that predate R6RS. It would help a lot if one .sld file could cover all R7RS-capable implementations, even if (cond-expand ...)s have to be written inside the file.

Reading csm's manpage, it seems to handle .sld files just as well as other kinds, but since it's not part of core Chicken, people tend to write eggs and other code in .scm files using (module ...) forms which complexifies the task of porting that code.

Here's an example of a real library that's provided as both a Chicken egg and a R7RS (and R6RS) library in the same git repo: The implementation code that does the heavy lifting is shared among all three (packrat-r5rs.scm) but the library wrappers are all different (), and there's a little magic in packrat.egg and packrat.setup to enable things.

reply via email to

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