[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
>>>>>> "felix" == felix <felixundduni@xxxxxxxxxx> 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
>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)
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
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)
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).