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