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