Re: [Chicken-users] Bug with #:optional in args egg?

[Jim Ursetto]

On Jun 19, 2017, at 4:25 PM, Diego A. Mundo <address@hidden> wrote:

With the example on the args eggref (http://wiki.call-cc.org/eggref/4/args#examples) slightly modified to this:

…

You can see how the behavior of using required arguments (-e or --elephant) differs from using optional arguments (-d or --depth). More specifically, -e and --elephant work, parsing their arguments as expected, whereas -d produces #f except when the option is passed directly after the flag with no spaces (-d10, for example), and --depth always returns #f.

Basically, SRFI-37 is a bit broken and, as a thin layer on top of it, the args egg should probably be considered deprecated because of that (although, it does work in a pinch). Not to mention the questionable use of macro syntax the args egg demands.

The issues you mention are documented, in a sense, in args-examples.scm in the SVN repository. Unfortunately it looks like I didn’t actually put this in the wiki documentation proper:

;;; Note that missing required args can only be detected if their option appears last,

;;; and optional args must not be separated from their option by a space

;;; (e.g. -d2 or --debug=2, not -d 2 or --debug 2).

Optional arguments are a little iffy in the first place. To avoid confusion in parsing, you basically have to implement them as in SRFI-37, requiring an = or no interceding space, because otherwise it’s too easy to interpret an operand or option as an optional argument value. The SRFI specifies that operands and options can be intermingled in any order, making this even more important.

Another problem with SRFI-37 is that (as mentioned above) missing required arguments can only be detected if they come last on the command line — because the reference implementation, at least, will consider “--foo --bar” to be an option of “--foo” with a value of “--bar”, so the value can never be missing! It’s possible the SRFI-37 implementation could be rewritten to consider “--bar” to always be an option, never an argument, unless occurring after the “--“ end of option string.

Anyway, I would avoid using the args egg because the behavior of SRFI-37 as specified is not really what we expect from modern argument parsers.

Jim