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 <[EMAIL PROTECTED]> 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. _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
