Re: Starter project: getopt_long in Ada

[Natasha Kerensikova <lithiumcat@gmail.com>]

On 2011-11-28, Georg Bauhaus <rm.dash-bauhaus@futureapps.de> wrote:
> On 26.11.11 19:13, Natasha Kerensikova wrote:
>> 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.

I think we had a bit of a misunderstanding about the word "state".

My point was that I couldn't (and still can't) think of any example
where an *internal* state for handlers is needed. Of course,
command-line flags have to change something, otherwise it's useless to
parse them, but they change a *global* state.
Or at least an externally-visible state, if you prefer to query a
global object rather than have a collection of global variables
(I prefer releasing everything related to argument parsing before
starting the actual processing, but that's a personal taste.)

The verbosity level is most likely an integer, conceptually in a global
state (even if it's hidden behind a function rather than in a global
variable), and -v handler only communicates with the global state.

For case 2 it's a bit more difficult to answer, it depends on the rest
of the design, whether the handler launches some actual processing or
only record the arguments in a friendlier format to be executed at some
later point.

Anyway, we actually agree on the necessity to have a state, and I admit
I didn't think of the possibly of having the parsing object (whose
dispatching subprograms replace the current access-to-subprograms) be
also a holder for the global state.

> Do not worry about efficiency of indirect calls.

To be honest I really don't. Especially since we were talking about
command-line argument parsing, which is seldom a performance-critical
piece of code.

And the difference cannot really be worse than an extra
dererefence/memory access, which is also negligible is most situation
even when performance matters. It might be significant for
memory-constrained devices, but I've never come close to any such
device (even though I would love to).

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

I would be quite confident there is no difference between these snippets
on 21st century i386 processors.

What does make a difference, although probably small, is that in the
first case an address has to somehow end up in eax, while the second has
a ready-to-use constant. I would guess that the address in eax is loaded
from memory (hence the extra dereference/memory access I keep
mentioning), or maybe somehow computed. And that's the efficiency
difference between both situations.

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

I will have to think deeper about it. Right now I'm mostly realizing
that I have no idea how discriminants and type expansion in interact:
can I expand a constrained root? Or do I have to constrain the instance
of the derived type? And few other considerations like that. It looks
like it's time to stop writing and go reading for a while.

Thanks a lot for the pointers,
Natasha