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.
>>>>> On Sat, 23 Jun 2001 01:07:44 -0400, Marc Feeley <feeley@xxxxxxxxxxxxxxxx> said: > I'm not sure I understand what you mean by this... that it is > trivial to implement an unwinding exit in the current SRFI-22 > proposal using a call/cc and set! in main? Perhaps it is easy to > type in, but it does not eliminate the semantic wart (an exit inside > a dynamic-wind after thunk). I agree with Marc on this. I think that it would be best to have an exit-ignore-wind procedure that ignored the dynamic-unwinds (although unlike Marc I rather like them), and an exit-with-unwind procedure (or unwind-exit) that respects the dynamic-winds. As it is easy to emulate the latter with the former but not vice-versa, I agree that the former really should be provided. I think the symbol ``exit'' should be bound to the former. If you really thought the unwind semantics were more important, I suppose you could bind ``exit'' to the latter. In a fit of indecision, you could even leave it unspecified which of the two procedures ``exit'' was bound to, but I think that would be a mistake. As for leaving this to another SRFI, it seems that the semantics of exit are completely related to the topic of this SRFI: running scheme programs as OS tasks. Therefore what ``exit'' does is directly related to what ``main'' returns, so it is very clear to me that they should be specified together. This is the first time I have re-read the SRFI since it was originally posted, and I have a few comments: 1) In the section ``Script Interpreter Invocation'' the line about 64 lines lacks context. Perhaps something like, ``The 64 character limit for the first line of the script is to be consistent with the limits imposed by the worst-case extant Unix systems. Perhaps it should just disappear from here as it is much better discussed below. 2) It is not completely clear that the symbols scheme-r<em>n</em>, scheme-ieee-1178-90, scheme-srfi-0, and scheme-srfi-7 are the *only* valid symbols in the script line. I would also suggest that the R-number of the scheme-r<em>n</em>, be any n>=4 (and perhaps also the IEEEs, but I am less sure you should anticipate other configuration SRFIs.) 3) In the last line of semantics, it would seem to me that absolute filename paths would also be acceptable (although I can see an argument to only allow relative). 4) I don't understand what the section ``Compilability'' is saying, at all! It doesn't seem to have anything to do with compilability, and perhaps should be folded in with the invocation section above. 5) The <H2>s in ``Design Rational'' perhaps should be 3s or 4s since on my browser (Netscape 4) they show identically to the 1s. 6) ``Absolute Script Location vs. Trampoline'' assumes the reader knows it is talking about the difference of #! scheme-srfi-0 versus #! /usr/bin/env scheme-srfi-0 without saying it. I'm sure most of the target audience will figure it out, but it requires a bit of thought and breaks up the flow. 7) For Windows, I think it would be better to point out Eli Barzilay's comment about dispatch being on the basis of file extension and that the rest of the SRFI stands rather than fortell a 1-line SRFI that says that. Gee... I think that's about it! I'm glad to have the SRFI here so I can continue to avoid Perl. Thanks ../Dave