This page is part of the web mail archives of SRFI 22 from before July 7th, 2015. The new archives for SRFI 22 contain all messages, not just those from before July 7th, 2015.
Why? The cost is negligible, the benefits substantial, and the alternative you propose is way baroque. Baroque, to me, is firing up a whole interpreter simply to execute the interpreter I orginally had in mind. That is applying way more resources to the task than it needs, by orders of magnitude. Note, again, that I'm not saying remove the ability to do so. I'm simply saying that if you introduce one extra switch -- which is already implemented in fairly portable code -- you can also support direct execution. The meta-switch is simpler, not more baroque, because it works directly with the semantics of the *operating system*. Unix. The kernel. The exec() system call. It doesn't require a whole 'nother software system to get in on the act in order to work. That is simple & pure. Get /bin/sh out of the picture as a *required* component. People actually do occasionally roll oddball reduced Unix systems based on a kernel with an interestingly different init process & other selection of binaries. It'd be nice if this scripting standard you are establishing had no *required* dependencies beyond the Unix kernel. Olin> Also, I'd suggest making the terminator be newline-bang-sharp, not Olin> simply bang-sharp. Makes the possibility of a false positive even Olin> less likely. I don't see a great likelihood for a false positive. I don't either. It would not be a big deal if you went either way. On the other hand, it would cost nothing to reduce that likelihood further. I think. I can't think of a way in which newline-bang-sharp would *cost* you anything. Can anybody else? Olin> 5. The draft says Olin> In the case of -srfi7 all specifications of filenames Olin> (marked by <filename> in the syntax of SRFI 7) are strings Olin> containing Unix-style filenames relative to the directory Olin> the script resides in. Olin> Err... are you *sure* you want to do that? Yes. If I'm not mistaken, scsh behaves in the exact same way. Yeah, let me withdraw that. Olin> This is problematic for other reasons, as well. What if I Olin> want to load stuff in from some standard library directory, Olin> regardless of where you might locate my script? Are you Olin> disallowing absolute pathnames? No, I'll be more explicit about that. Olin> If you really want to do this relative-to-the-script pathname Olin> resolution, you might be better off saying that *relative* Olin> pathnames are interpreted this way, and absolute pathnames Olin> are simply absolute filenames. OK. Excellent. What I'd really like is ways to specify multiple resolution strategies for pathnames, something like ".." and <..> in cpp's #include directive. Common Lisp's filename stuff lets you specify "logical directories". If one had a syntax in Scheme for this, one could define a logical dir that represented a host-specific search path of dirs. But that is far beyond the scope of this SRFI; I'm just rambling. -Olin