This page is part of the web mail archives of SRFI 37 from before July 7th, 2015. The new archives for SRFI 37 contain all messages, not just those from before July 7th, 2015.
On Tue, 24 Sep 2002, Robert Bruce Findler wrote: > > 2. Cmdline seems to support more than one argument per option. Args-fold > > supports 0 or 1 arguments per option, following the lead of POSIX/GNU > > guidelines. > > This turns out to be useful for many things. One I use a lot in plt > scheme is loading a library: > > mzscheme -L errortrace.ss errortrace -r myscript.ss > > is a convient way to debug my script: the first three arguments specify > that the debugging code is loaded before the script is executed. The -L > flag means "take the next two arguments and pass them to `require' as a > library". In this case: > > (require (lib "errortrace.ss" "errortrace")) > > Without multiple argument commandline options, this becomes tricky. I can see how this would be useful. You can actually almost do it with the current args-fold, by collecting the additional arguments with the operand-processor (I say almost, because you couldn't catch extra arguments that look like options), but obviously it would only be realistic to do this in a pinch for a quirky interface. > Does the GNU/POSIX spec give a rationale for only allowing single > arguments? I haven't seen any explicit rationale, as in most areas they seem to have just standardized the historical design. I have some questions about multiple arguments, since I have never used them or seen them used: 1. What do they look like? Long option arguments look like this: --foo=bar so do long option multiple arguments look like this: --foo=bar1 bar2 Does this seem strange, somehow? Short option arguments look like this: -fbar or -f bar so do short option multiple arguments look like this: -fbar1 bar2 or -f bar1 bar2 2. How do multiple option arguments interact with optional option arguments? There is already ambiguity which must be resolved when dealing with optional option arguments, and with grouped short options, do multiple option arguments make things worse? Perhaps not. 3. Usually when you need something like multiple option arguments, you just sub-parse a single option argument. For example: -f "bar1 bar2" Given this existing idiom, is it worth upsetting the status quo with a new feature? Would it confuse application users, who probably expect the old idiom? -Anthony Carrico