>>>>>> "felix" == felix  <xxxxxx@freenet.de> writes:
>
>felix> I have some trouble with the fact that an error in the invocation of
>felix> "main" is supposed to return EX_USAGE. Specifically
>felix> I have trouble thinking about a way to implement it in
>felix> a not too arcane way.
>
>You're summing up my original reservations about this issue.  I do
>believe yielding the correct exit code is important, but I also would
>slightly prefer to leave that responsibility to the programmer of the
>script.
>
>Marc, how about you step in here?

Well, I do find it odd that there is a different error code for the
case of a wrong number of arguments.  But if it is the "Unix way" then
I can understand wanting to support it properly.

In terms of implementation, I don't see how to do it (at least in
Gambit) because the "main" procedure might tail call another procedure
(or even itself) with a wrong number of arguments, as in:

(define (main a1 a2)
  (main a1))

and I can't see how to distinguish the first call (in the runtime)
from the second, and the SRFI requires each call to return a different
error code.

I thought it would be possible to use Gambit's continuation
introspection mechanism to extract the continuation's parent (the
procedure that created the continuation) or the error mechanism which
puts a reference to the procedure and list of arguments into the
exception object, but that is not sufficient for the simple example I
give above.  Note that the "wrong number of arguments" error is
detected by Gambit on **entry** to the procedure (i.e. the procedure
call has already occured).  In a system that detects this error in the
caller I guess it would be easier to satisfy the SRFI specs.

Note however that the error reporting process can't be completely
automatic (in an R5RS script).  If a script accepts from 3 to 5
parameters then it is up to the main procedure to return EX_USAGE when
too many arguments are given as in:

(define (main a1 a2 a3 . others)
  (if (> (length others) 2)
      ...EX_USAGE...
      ...keep going...))

If the script author does not put this test in (which is probably very
likely in quickly written scripts) then in practice the distinction
between EX_USAGE and EX_SOFTWARE will be lost anyway, so why bother.

So my position is that only EX_SOFTWARE should be required by the
SRFI.  If the script author wants to support EX_USAGE, then she can
program it into the script explicitly (using a "main" with a rest
argument and appropriate logic).

Marc