Hi Zelphir, Just as a heads up — this is perhaps a little tangential. I created the guile-config package (https://gitlab.com/a-sassmannshausen/guile-config), which builds on getopt-long to provide a (IMHO) richer and more sustainable approach to managing commandline options for a program.
Just figured you might be interested to have a look, as you were curious about the subject matter. HTH, Alex Zelphir Kaltstahl writes: > On 08.07.2018 18:00, guile-user-requ...@gnu.org wrote: >> ------------------------------ >> >> Message: 3 >> Date: Sun, 8 Jul 2018 08:44:22 -0700 >> From: Matt Wette <matt.we...@gmail.com> >> To: guile-user@gnu.org >> Subject: Re: Parsing command line arguments, predicate error >> Message-ID: <e9c9c87b-389d-70d1-7afe-13a0b03e1...@gmail.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> >> >> On 07/08/2018 04:49 AM, Zelphir Kaltstahl wrote: >>> Hi! >>> >>> I decided to take a look at how one can parse command line arguments in >>> Guile and was looking for something like argparse in Python. It seems >>> that (use-modules (ice-9 getopt-long)) does the job, except that I hit >>> one problem and don't know what the mistake I am making is. It seems to >>> be connected to the usage of `predicate` in my code. >> You probably want to use quasi-quote + unquote: >> ? `((version ... (predicate ,string-exact-integer?)))) >> >> I believe the module (srfi srfi-37), args-fold, is now recommended over >> getopt-long. >> >> Matt > > That solved the problem, thank you Matt! > I was so far quite fond of the way one specifies options with > getopt-long, but the quasi-quote unquote was not mentioned in the Guile > docs and feels unnatural. There seems to be no reason for it to force me > to do that, except that it does not work otherwise. I'll probably look > into how it is done with SRFI-37, because of this. > > Apart from this issue, what are the reasons for SRFI-37 to be > recommended over getopt-long?
