>>>>> On Sat, 23 Jun 2001 01:07:44 -0400, Marc Feeley <xxxxxx@iro.umontreal.ca> 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