[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Zbigniew
Subject: Re: [Chicken-users] Facilities on top of SRFI 37: args-fold
Date: Mon, 6 Jun 2005 15:17:23 -0500

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]