Re: [Groff] Re: getopt() as gtroff macro ?

[Keith Marshall]

On Thursday 23 September 2004 7:56 pm, Steve Izma wrote:
> Hmmm. I now realize I didn't think this through completely before
> replying last time, so it's now more apparent to me what Keith
> was doing.
>
> I like python's facility for this, but one reason, I think, that
> it works so well is because of how easy it is in python to step
> through a list, so that you can set up a "while" loop and step
> through each option and write the appropriate code for each one,
> if it's present. I would prefer to avoid calling outside macros to
> process the options and instead just be able to set flags and
> variables.

Indeed.  My sample macro code -- which was derived from actual working code 
-- was designed to simulate the behaviour of a 'switch' within a 'while' loop 
in C code, (which is how option parsing is C is traditionally handled with 
the getopt() function), and my option handler macros providing the 'case' 
implementations.  I don't know Python, but I assume its getopt module 
operates in a similar fashion.

> How about having getopt set local variables based on the option
> names, both the long or the short ones (one could choose between
> readability and conciseness). Flags would always
> be numeric (essentially boolean) and options with values would
> always return a string, which if numeric would require a unit
> designator [...]

Thinking about this, I believe it should be feasible, and may indeed offer a 
better and more robust implementation than requiring the user to provide call 
back macros.  Using macros certainly offers greater flexibility; however it 
also places an additional burden of initialisation on the user.  By 
stipulating that flags are always returned in registers, and option arguments 
are always placed in strings, we can handle the initialisation in a 
consistent manner, and the user is assured a consistent API to the .getopt 
request.

For initialisation, I would suggest that all possible flag registers are 
defined with zero value, and all possible option argument strings are either 
guaranteed to be undefined, or, perhaps preferably, are defined with zero 
length, prior to parsing the argument list.

I do believe that the user should be required to provide two call back macros 
-- one to handle the case of parsing an undefined option, since IMHO the user 
*needs* to be able to choose the appropriate action, and the second to 
process the arguments which remain, after the options have been stripped.
I think this second used supplied macro should also be required to perform 
*all* of the user defined processing which requires access to the flags and 
strings set by .getopt, thus allowing .getopt to take the responsibility for 
removing these flags and strings from their respective namespaces, on 
completion.

As a final observation, if both long and short options are declared to 
control the same function within the user's call back code, then the user 
must explicitly take responsibility for interpreting both forms equivalently. 
I can see no reliable way of handling this implicitly, within any .getopt 
implementation.

Best regards,
Keith.