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