> On Jun 26, 2021, at 3:26 PM, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> Since Scheme has many standards and implementations, we have the added complexity of dealing with them all. A lot of the groundwork for portable Scheme scripting has already been laid via RnRS and SRFI, and it works fine for many real tasks, given that we can say to the Scheme implementation which RnRS we are using. (Scripts use #! lines, which don't easily support command line flags, so some mechanism of writing something in the source file to distinguish the RnRS edition would be best.) We should also have a mechanism to specify which Scheme implementations the script supports, since a non-trivial script with even simple environmental dependencies is still unlikely to work in a new Scheme implementation with no modifications.
>
> Something like "autoconf on the fly" or "environment manager on the fly" would be a reasonable way to describe the proposed script launcher. It would look at the declarations in the script, figure out something like "the script says it is written in R7RS and supports Chibi, Chicken, and Gauche; we have Chicken; if we use Chicken, the script says it needs eggs A and B, so I will have to call out to chicken-install to ensure those eggs are installed". Finally, it would exec csi (the Chicken interpreter) with the right command line flags to run the script.

I think it would be good to keep the scheme-script “dispatcher" as simple as possible.  The script’s code can use cond-expand to account for differences in the host Scheme system, so that the dispatcher is just a simple exec of the host Scheme interpreter.  All R7RS systems must support cond-expand and SRFI 0 is one of the most widely supported SRFIs and was designed for writing portable code.  Ideally the cond-expand should be used sparingly, to keep the code easy to understand, but it can be used in the initial part of the script to “bootstrap” the code’s portability, for example to determine if the host Scheme is an R7RS system to be able to use (import …) and define-record-type.

For those implementations that don’t have builtin support for SRFI 0 the scheme-script dispatcher could use a system specific approach to provide cond-expand (prepend a macro definition for it, prepend #!r6rs and a suitable (import (srfi 0)), add a command-line option, etc).  If the scheme-script project becomes popular, as I hope it will, implementors of those Scheme systems may be inclined to add support for SRFI 0 either builtin or through a command line option.

Having a lightweight dispatcher will allow easier debugging when using a Scheme system that provides SRFI 0 natively because it will be possible to directly specify debugging related command-line options that would be hard to specified otherwise.  For example with Gambit:

    gsi -:dar _test _define-library/debug myscript arg1 arg2

If the name “scheme-script” is too controversial then the name “scheme-script-ce” should be considered, where the “ce” suffix stresses the fact that the script can assume cond-expand is available.

Marc