Several comments
shivers@xxxxxx
(10 Mar 2001 02:57 UTC)
|
Re: Several comments
Per Bothner
(10 Mar 2001 03:48 UTC)
|
Re: Several comments sperber@xxxxxx (10 Mar 2001 08:50 UTC)
|
Re: Several comments
shivers@xxxxxx
(10 Mar 2001 17:23 UTC)
|
Re: Several comments
Martin Gasbichler
(11 Mar 2001 14:31 UTC)
|
Re: Several comments
Marc Feeley
(20 Mar 2001 16:14 UTC)
|
Re: Several comments
sperber@xxxxxx
(20 Mar 2001 16:33 UTC)
|
Re: Several comments
Marc Feeley
(20 Mar 2001 17:11 UTC)
|
Re: Several comments
sperber@xxxxxx
(22 Mar 2001 08:27 UTC)
|
Re: Several comments
Marc Feeley
(22 Mar 2001 13:05 UTC)
|
Re: Several comments
sperber@xxxxxx
(22 Mar 2001 13:29 UTC)
|
Re: Several comments
Marc Feeley
(22 Mar 2001 15:06 UTC)
|
Re: Several comments
sperber@xxxxxx
(22 Mar 2001 15:11 UTC)
|
Re: Several comments
Marc Feeley
(22 Mar 2001 15:28 UTC)
|
Re: Several comments
Per Bothner
(22 Mar 2001 17:01 UTC)
|
Re: Several comments
Marc Feeley
(22 Mar 2001 18:22 UTC)
|
>>>>> "Olin" == shivers <xxxxxx@cc.gatech.edu> writes: Olin> 2. It is a general Unix convention that interpreters read from their Olin> stdin, but alternately take a Olin> -c <exp> Olin> switch. You might consider adding this as an alternate to the Olin> -call <entry-point> Olin> option. Hmm, good point. I'd hate to make the SRFI more bulky, however. What do others think? Olin> 3. Your design essentially *requires* a /bin/sh Olin> trampoline. Which I find annoying. Why? The cost is negligible, the benefits substantial, and the alternative you propose is way baroque. Olin> 4. This is a bogus spec: Olin> <script prelude> --> #! <any character including newline> !# Olin> One problem is the singular "character", when you mean multiple Olin> characters, of course. And the "anything including newline" spec Olin> isn't right, either, since !# isn't allowed. Here's my version: Olin> <script prelude> --> Olin> #! <any sequence of chars not containing bang-sharp> !# Olin> Is that better? Yes, good point. 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. 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. Olin> Invariably, a relative pathname in Unix means relative to the Olin> process' cwd. You are changing that rule, *only* in the case Olin> of code appearing in a Scheme script. That could cause weird Olin> surprises... No, I'm changing that for the *configuration* *describing* the Scheme script. 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. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla