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