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

[Zbigniew]

I'm guessing you mean something on the order of

'( (option (h help) #:none "Display help text")
   (option (f file) #:required "Load file"))

and then you would parse that and build both a usage string and a list
of options from it?

Currently I can create an options list like:

(list (args:make-option (h help) #:none "Display help text")
        (args:make-option (f file) #:required "Load file"))

which will be evaluated by the interpreter into a list of options
objects; then I could feed that options list separately to a function
that generates the usage (pulling the data from the options objects). 
In effect the "parser" logic is in the make-option macro and the
interpreter.

Is there a reason to prefer one over the other?  Is it better to parse
these kinds of structures yourself, or evaluate them?  (I am still new
at this lack of data vs code distinction)

I would be interested in an outline of your idea even if you can't
find your code.

On 6/6/05, Michele Simionato <address@hidden> wrote:
> On 6/6/05, Zbigniew <address@hidden> wrote:
> > 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.
> 
> Well, in Python I had to parse the usage string, in Scheme I would just
> write the usage message as an s-expression, and I would generate the
> usage string from it. So, no parsing problem at all.
> I did some experiments months ago but I don't find the code now.