[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in getopt-long?
From: |
Thien-Thi Nguyen |
Subject: |
Re: Bug in getopt-long? |
Date: |
Thu, 02 Aug 2001 05:20:50 -0700 |
From: Daniel Skarda <address@hidden>
Date: 02 Aug 2001 11:32:34 +0000
I think that getopt-long arguments should be independent and one
should not imply another. If I had needed to make '--test' argument
mandatory, I would have wrote '(required #t).
see latest cvs (in either stable or unstable branch) for a mechanism
that allows you to express what you expect to see and also test guile's
actual behavior: test-suite/tests/getopt-long.test. because the spec
definition is somewhat confusing (to me at least), i would prefer to
center discussion around the concrete tests in this file rather than
easy-to-misunderstand (by the sleep-deprived ;-) descriptions. the
tests there are just a start -- they should be expanded greatly to cover
all the nooks and crannies of (ice-9 getopt-long).
There are a lot of optional arguments, which you would like to check
for correctness (using `file-exist?' - for example) and it does not
make sense to check optional arguments in different way than
mandatory arguments.
Maybe we also can improve getopt-long error reporting by adding one
option - predicate-failed - something like this...
(getopt-long args
`((input-file
(value #t)
(predicate ,file-exist?)
(preciade-failed ,(lambda (x) (%% "Can not find file ~S" x))))))
... because 'option predicate failed' is not too informative :)
(I use @@ as a shortcut for (apply format #t args) and %% for (apply
format #f args))
this allows the right amount of flexibility for the user. if you're
feeling motivated, consider cleaning up getopt-long.scm, beefing up
getopt-long.test, and submitting a patch. i think such a patch would be
well-received. personal note: i'm incommunicado for almost a week and
won't be responsive to guile-devel discussion for the duration; please
don't construe my silence as lack of interest...
thi