This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Automated Option Processing for Guile



Hi Matthias, et al.,

I was looking at embedded Guile when suddenly I saw how
easy it was to make AutoOpts available to Schemers that
link their own main() routine into their programs.
The config files and command line options could be
easily processed by my library and exported to the Scheme
environment.  The question I have is, "What would be the
best form to do that in?"  Your question may be, "Why
would I want to do that?"  I'll answer that at the end.

====================

First, a C example of AutoOpts:

Given an option definition file as in:

  prog_name = mumble;
  long_opts;
  flag = {
    name  = bumble;
    value = b;
    desc  = 'this does bumbly things';
  };

the C program does this:

  if (HAVE_OPT( BUMBLE ))
    mumble_bumble();

If this option were to have an argument, then
you would add the attribute ``flag_arg = ":";'' and:

  if (HAVE_OPT( BUMBLE ))
    mumble_bumble( OPT_ARG( BUMBLE ));

finally, if the option may be specified an arbitrary
number of times, you would add the attributes
``max = NOLIMIT;'' and ``stack_arg;'', and:

  if (HAVE_OPT( BUMBLE )) {
    int    ct = STACKCT_OPT( BUMBLE );
    char** av = STACKLST_OPT( BUMBLE );
    while (ct-- > 0)
      mumble_bumble( *(av++) );
  }

====================

So, what would be the best form for representing these
data in Guile and what would be the best way to do that?

My first guess would be to create a ``have-opt-xxx'' for
each option and set its value to ``#t'' or ``#f''.
Then, if the value is ``#t'' and the option has an argument,
then set ``opt-arg-xxx'' to either the string or list of strings
that are represented by the command line and config file options.
Finally, there is the notion of adding a special disablement
prefix to long option names.  e.g.  ``disable = dont;'' would
enable the long option  ``--dont-bumble''.

The other method would be to export a collection of functions
to Guile that would basically implement the C macros above.
You would have to use them a la:

  (if (have-opt "bumble") ....

I am open to anyone's suggestions....

====================

Why would anyone want to do this?  Because once the library
is installed, you never have to write an option processing 
loop ever again.  :-).  It handles your command line options.
It handles config/rc/ini files.  It can rewrite them, if you
want.  It handles environment variables.  It does the common
(and easy) option validations (conflicts & requirements).
It accepts a line of text from your program so you can embed
options in files your program processes.  It produces USAGE
text.  It produces a man page.  It produces the invoking
section for your info-doc.  It handles arguments for C programs,
C++ programs and shell scripts.  Now, it will do that for Guile
programs, too.  Perforce, the usage text will be consistent  :-).

Why would you *not* want to use it?  ;-)

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]