chicken-users
[Top][All Lists]
Advanced

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

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


From: Michele Simionato
Subject: Re: [Chicken-users] Facilities on top of SRFI 37: args-fold
Date: Tue, 7 Jun 2005 04:36:14 -0400

On 6/6/05, Zbigniew <address@hidden> wrote:
> 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?

Yes, exactly.

> 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.

Yes, this is *very* similar to my own version (I have found the code now).
 
> 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)

Well, this just the coolest idea of Scheme/Lisp ;)

The trick is that your final user will only set some configuration (in the
Python case it will just write the docstring, in Scheme he would probably
write a list) and the parsing logic will be completely hidden from him. 
In other words, with this approach you are essentially defining a 
declarative minilanguage for argument parsing. This is not the case if the 
user has to explicitely call functions such as make-option. Choosing
the declarative approach or the explicit approach is a matter of
taste. As an user
I am lazy and  I don't want to know about implementation details, so I
prefer the
declarative way. OTOH, the explicit way is easier to debug and more
clear in case something goes wrong. The declarative way requires a
little more effort from the implementor, since it hast to be implemented 
on top of the explicit way, possibly with some helper macro.

            Michele Simionato




reply via email to

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