Hi Lassi,

thank you for this explanation. So your approach is actually rather different than what is described in the non-normative appendix D of the R6RS.

In the understanding of this appendix, a script is just any top-level program packaged in a standardized form so that it becomes executable by the host OS.

You, on the other hand, don't view every "conventional program" as a "script" and vice versa. Moreover, as the script interpreter in the shebang line of your approach isn't necessarily a Scheme implementation but calls one after parsing the script, the script in your approach does not even have to be an RnRS top-level program. In essence, we have to agree on some format from which the script interpreter can extract source code for various Scheme implementations; even automatic unpacking of shar-like-packaged source code could be possible. Moreover, the script in your approach could even include library definitions, which is not possible with top-level programs.

This approach can become very helpful and wide-reaching. It is orthogonal to the R6RS (and the SRFI 22) approach and won't reinvent a wheel.

As a side note, this is another reason why it makes sense to choose a different name for the script interpreter executable, namely because its scope and function are different from R6RS's scheme-script.

Marc

Am Sa., 26. Juni 2021 um 21:26 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
> Ignoring the name issue for a moment (which can be easily fixed at any
> time), can you describe a bit more what you mean by portability above?

Sure. (I'm still thinking about; will reply when more clarity.)

> Are you looking for the creation of a new Scheme standard that
> encompasses existing standards and versions?

Not via this organization; this was created just to show that Scheme
scripting is possible and fun as it is.

If writing useful scripts gives us the clarity to design a comprehensive
scheme-script (by that or another name), so much the better.

An entire combined Scheme standard would be an enormous amount of work,
and should be pursued as a separate project. (I will enthusiastically
back anyone who tries! and may try to do some groundwork myself.)

> Or are you more looking for
> portability in the sense of Autoconf in that your script interpreter
> tries to present the script in such a way to the local Scheme
> installation so that it is execuatble by it?

"Script" and "scripting" are vague terms, but to me, the essence of that
activity is programs that are smaller and/or less polished than proper
programs; large scripts may eventually grow into conventional programs.

Since the essence of scripting is to start from nothing and gradually
hack something together, it's important to have a low barrier to entry.
Scripts are generally grown from a single source file, and when we add
more source files, we may intuitively start calling them "programs".

However, practical scripts need to use libraries to get a lot done with
little code. This to me suggests that it should be possible to declare
library dependencies in the script file itself. (Declare them in a
separate file, and the contraption starts to look more like a "project"
than just a "script".)

The most practical way to get libraries is to download third-party libs
from places like Akku, Snow-Fort, and Chicken eggs. We can write (import
...) in source files; it's not much of a stretch to permit people to
also write where those libraries can be downloaded from, and such ease
is very much in line with the spirit of scripting. Scheme could outdo
even Python and Ruby in ease of use.

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.