[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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