[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SRFI 22 release candidate #3
>>>>> 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
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
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
#! /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
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.