Re: [Chicken-users] Facilities on top of SRFI 37: args-fold

[Zbigniew]

I like your recipe.  Given a robust enough parser and perhaps some
very minimal markup to help it along, it would cover a lot of cases. 
The only problem is, it does not  allow you to add a processor
function for each option.

In practice, though, I wonder how useful the processors are---the
examples just use them to set global variables, since options do not
usually "do" anything, they affect the behavior of the program as it
runs.  Avoiding tons of global variables is the main reason I wrote
args:parse, it will return an option/arg alist after processing. 
Processors are neat for --help or --version, but...  Similarly,
operand parsing sounds good (a simple test might cat each file to
stdout), but you can't guarantee all options have been read unless you
insist operands come last.  In this case, you might as well just
collate them (like args:parse) and process them all later.

I considered generating help text from the options themselves (I think
PLT does this), modeled after GNU utilities such as ls.   The header
and footer of help text can vary widely---one solution is to generate
a string containing only the options and let the user embed it as he
wishes.

Disadvantages are, you need a way to add a documentation string to
each option, which clutters things up, and also args:make-option
currently makes a SRFI 37 #<option> -- which has no slot for a doc
string.

On 6/6/05, Michele Simionato <address@hidden> wrote:

> I did the same something like 10 months ago, but then I got frustrated by
> other things and never finished it.  My idea was to extract the options
> from the usage string, similarly to what I did in this recipe:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/278844
> 
> As you say, args-fold is neat in principle, but inusable in practice,
> so we really need
> an easy-to-use wrapper for it.