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.
>Marc> No, this is a secondary motivation. The prime motivation is that
>Marc> you get to name parameters explicitly rather than using "list-ref", etc.
>
>Ah, but then it does seem as though putting in that additional APPLY
>would not be so bad, or would it?
I see it the other way. If the script author wants greater control
she can use a rest parameter (and also possibly an APPLY) and return
EX_SOFTWARE when appropriate. If she doesn't mind that a wrong number
of arguments to the script is handled with an EX_SOFTWARE, which I
think is the more common case, then she specifies in main's parameter
list exactly the parameters expected, and APPLY is not needed.
While I'm on the subject, I can't say I'm very fond of having main
return a status code. I don't like it for C and I don't like it for
Scheme. Main should be a procedure. If main returns normally, then
the result is ignored and the EX_OK status code is returned from the
script. You can always call "error" to return an EX_SOFTWARE (this
will work even if "error" is not defined!...). The ability to return
some other status code should be left to an "exit" procedure (defined
in this SRFI or some other one), because it is common to want to bail
out of a program/script from a deeply nested computation. In the
absence of "exit" you have to use call/cc as in:
(define exit #f)
(define (main a1 a2)
(call-with-current-continuation
(lambda (cont)
(set! exit cont)
...body...
0)))
but this is needlessly ugly, and it still contains a reference to 0
for EX_OK, which will throw off beginners for sure. In fact, what
happens in your proposal if main does not return an exact integer, or
returns an integer outside the acceptable range?
Marc