> Your suggestions about "exit" are certainly very true, but as you correctly
> point out, the semantic issues of a "standard" "exit" are rather unclear,
> and IMHO it would be better to leave it out alltogether.
> Defining your own "exit" is trivial,

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).

> and if the user makes use of "dynamic-wind",
> the she should be aware of the consequences and write her code (and her
> unwinding thunks) carefully (she has to do it anyway).

It is easy for anyone, experts included, to miss this problem with
exit+dynamic-wind.  I would like the proposal to contain a "simple"
exit with straightforward semantics even when combined with
dynamic-winds.  If someone wants the unwinding semantics, they
probably have thought out the implications, and they can build it on
top of the "simple" exit with a call/cc and set! (see my previous
message).

Anyway, my original point was that I disliked having "main" return an
integer status code and having a bare 0 at the end of main's body
(which will confuse the beginner).  I would much prefer if the result
of main was ignored and EX_OK was returned in that case (this was the
prime reason why I suggested adding "exit", the exit procedure is of
secondary importance).  So I don't mind if exit is defined in another
SRFI, I just don't want main's body to end with "0".

Marc