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.
> And here's another one. You probably won't be too pleased with the > changes: > > - Because of the semantic issues, we decided to revert on the > parameter-passing issue. > > - Because of the semantic issue and to keep the namespace clean, we > decided against putting in EXIT. We have every intention to cover > this in a separate SRFI. > > We're still willing to be convinced on these two issues, but we need > better arguments than the ones we heard so far, along with resolutions > of the problems mentioned. We intend to release on You are correct... I am not pleased. Whether it is specified in this SRFI or another one, the exit procedure can either unwind the dynamic-wind stack or not: 1) unwind: cleans things up nicely for code that uses dynamic-wind without the user having to do anything special, but what happens if some dynamic-wind "after" thunk needs to call exit because some fatal error occurs. R5RS leaves the precise behavior undefined, and an infinite loop might occur. [In case you don't already know, I don't like dynamic-wind for many reasons... but that's a different ballgame.] 2) do not unwind: the program immediately exits (after minimal runtime system cleanup like flushing stdout/stderr) and there are no recursion issues (i.e. it is OK for an "after" thunk to call exit). This is good because it makes exit modular (i.e. the pieces of code that call exit don't have to be aware of the dynamic extent in which they might be). If the user prefers an "unwinding" exit he can always do: (define (main . arguments) (let ((real-exit exit)) (real-exit (call-with-current-continuation (lambda (cont) (set! exit cont) ...body of main goes here 0))))) If you don't include an "exit" in SRFI-22 then a user who wants to exit with a particular status code has to write something like: (define exit #f) (define (main . arguments) (call-with-current-continuation (lambda (cont) (set! exit cont) ...body of main goes here))) and then he is stuck with an "unwinding" semantics for exit, which would be unfortunate. Note that this issue is not particular to Scheme, for example C has both "exit" and "_exit" for both types of exits. Why not simply leave the semantics of exit undefined when it is used in the dynamic extent of a dynamic-wind. A future SRFI can go one way or the other for this particular case and still remain compatible with SRFI 22. As for the parameter passing protocol for "main", I maintain that the best approach is for main to receive as many arguments as were passed to the script. There is no loss of control (you can still specify a single rest parameter to give a EX_USAGE status if the number of arguments or their form is inappropriate) and it makes life easier for the naive script writer and "lazy" script writer (which I am), because the (fixed position) parameters are directly accessible and a reasonable error checking is done automatically. I know that this means that most Scheme implementations will incorrectly return the status EX_SOFTWARE instead of EX_USAGE... but if you are willing to write your script so that it checks and returns EX_USAGE correctly then the only extra cost in my proposal is a ". " to add to the parameter list of main. And frankly, I don't see much usefulness in distinguising EX_USAGE and EX_SOFTWARE. How would someone calling a script use this information, and for what purpose? I've quickly tested a few Unix utility programs (under Linux) and none return EX_USAGE for usage errors: % ls -w ; echo $? ls: option requires an argument -- w Try `ls --help' for more information. 1 % grep -o ; echo $? grep: invalid option -- o Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. 2 % wc -o ; echo $? wc: invalid option -- o Try `wc --help' for more information. 1 % perl -o ; echo $? Unrecognized switch: -o (-h will show valid options). 2 Marc P.S. I'm soon leaving for a trip and will be out of touch for 10 days. So don't take my silence as a sign of lack of interest in SRFI-22.