[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI 22 release candidate #3

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

> 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

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