Re: Starter project: getopt_long in Ada

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 26.11.11 19:13, Natasha Kerensikova wrote:



>  So maybe it would make sense to keep the
> access-to-procedure Callback argument, and create an
> Option_Error_Handler class, whose default value in Process would be
> something that just raises Option_Error (which would by the way make
> Process body cleaner by not having to check null access).
> 
...
> While I certainly agree with this in general, in this particular case
> I'm skeptical about (2), since I can't think of any example where error
> handlers are not fatal, which leaves only one handler that only has to
> communicate with itself.

Two use cases for stateful handlers that I can think of are

1) -v -v ... increasing verbosity, i.e., handling means counting
   the number of times an option has occured

2) Two options -A and -B must not occur ensemble, in any order or
   frequency (This is "inspired" by really complicated setups, such
   as the nightmarish command line interface of ffmpeg.)

In either case, the handlers would have to have a way to be
informed about prior occurrences.

> Yes, I'm completely sold on the idea of using a dispatching call instead
> of error handler accesses. And still unsure about the normal handler.

Both mechanisms should work. Though, for reasons of reduced complexity,
and streamlined interface, I'd prefer just one mechanism used for either
of regular handlers and error handlers. Doesn't hurt, and if later
the regular callback mechanism needs extension, the interface of
Process needs little change.

Do not worry about efficiency of indirect calls. It seems that there
is very little difference at the assembly level, in particular
when the compiler "dispatches" to the right procedure at
compile time, as is the default with Ada. (If the programmer
has not requested runtime dispatching explicitly.)


For illustration, in traditional Ada, one may pass a callback as a
generic formal subprogram. There is then no pointer. The following example
is from a translation with optimization turned on, but without any inlining
and checks turned off:

using a procedure pointer:

   0:	55                   	push   %ebp
   1:	89 e5                	mov    %esp,%ebp
   3:	83 ec 08             	sub    $0x8,%esp
   6:	c7 04 24 01 00 00 00 	movl   $0x1,(%esp)
   d:	ff d0                	call   *%eax
   f:	c9                   	leave
  10:	c3                   	ret

using a formal generic procedure:

  30:	55                   	push   %ebp
  31:	89 e5                	mov    %esp,%ebp
  33:	83 ec 04             	sub    $0x4,%esp
  36:	c7 04 24 02 00 00 00 	movl   $0x2,(%esp)
  3d:	e8 de ff ff ff       	call   20 <see_if_dispatching__assign.158>
  42:	c9                   	leave
  43:	c3                   	ret

Don't know if there is a difference at all in terms of
efficiency.

However, with checks turned on, the pointer version show a longer
list of instructions than that of the generic version.



> Having it a type discriminant like you suggest feels like an abuse of
> the type discriminant feature, but I cannot manage to tell why (and I
> might be wrong, considering I'm still too new to have accurate
> feelings).

If you remember that a discriminant acts a a subtype
constraint, your worries might be fewer: Once the constraint
has a value, the value will suitably restrict the set of
possible values of the type.  This might also mean
that operations can now select specific behavior depending
on the discriminant constraint. This constrains the set
of possible behaviors.

> However, is there anything wrong with having something like the
> following?
> 
> generic
>    type Option_Id is (<>);
> package Natools.Getopt_Long is
>    Option_Error : exception;
>    package Handlers is
>       type Argument_Handler is abstract tagged null record;
>       procedure Missing_Argument
>         (Handler : in out Argument_Handler;
>          Id      : Option_Id);   --  implementation raises Option_Error;
>       --  others handlers, maybe including regular argument callback
>    end Handlers;
>    procedure Process ( -- arguments to be written later
> end Natools.Getopt_Long;
> 
> Or is the inner package looking for trouble?

No, seems fine.