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