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