> Right -- I did see that there, and I posted on an internal PLT mailing
   > list where I met with opposition to requiring the extra quotes:
   >
   >   -L"first-arg second-arg"
   >   --long-name="first-arg second-arg"
   >
   > Oh well.

   I feel for you, I've heard private support for the opposite position off
   this list too. If anyone is passionate about this issue, speak up on this
   list please.

I'm not up on the contents of the proposed SRFI, or the PLT library.

I have written several argument crackers, in C and Scheme, and have
an opinion about this, based on the syntax illustrated above.

Sometimes, but not in general, an option argument is naturally a list
of items whose syntax permits a delimiter (typically either space,
comma, or user-chosen (similar to the sed `s' command)).   Typically,
argument crackers treat these exceptions as single arguments, and let
the splitting happen in other code.

In general, option _names_ come from a restricted character set, so it
is ok to have syntaxes which combine them in a single argument with
the option argument.  ("-Xfoo" or "--long-X=foo"). (Even with such
syntaxes, to avoid forcing callers to smash strings together, it is a
good idea to permit two-argument forms for those ("-X foo" and
"--long-X foo").

But, in general, the separation of multiple option arguments has no
fixed syntax.  Indeed, the separation of command line arguments in
general has no fixed syntax.  Introducing a fixed syntax usually makes
some option arguments impossible to pass (one couldn't write "first
arg" in the quoted example).  Rather, separating arguments is an
external issue, decided by whatever program builds the argv array.

Therefore, in general, an argument cracking library should probably
not define an internal syntax for combining multiple option arguments
in a single argument.  If it must define such a syntax, it ought to
allow quite a bit of flexibility, and that will likely lead to bloat
and complexity with little payoff.

Conventionally, multiple option arguments are handled one of two
ways.  Either with multiple options, as in GCC:

	gcc -L <linker-option> -L <linker-option-argument> -L <...>

or with a delimiter argument, similarly to how xinit handles optional
arguments:

	xinit  [[client] options] [-- [server] [display] options]

Those cases are so rare that most argument crackers do not treat them
specially and let programs combine the optional arguments and multiple
option arguments themselves.

There is a need, not _necessarily_ the purview of this SRFI, to more
carefully design the standard for command line syntax.   POSIX has its
standard, which, for historic reasons, not all POSIX programs honor
and which, for historic reasons, doesn't go very far.

(Extended) Scheme has the advantage over many shell languages that it
has an unambiguous, simple syntax for structured data built over an
extensible set of primitive types.  That syntax is simple enough to be
managed by other languages: much as XML is, but with less work, less code,
greater flexibility, greater generality, and improved readability.

So, it might be worth trying to define a restricted set of command
line grammars that would support, for example, multiple option
arguments cleanly.  But watch out for creating a syntax which is too
restricted (e.g. using space as a delimiter for otherwise arbitrary
strings), or one which is too complicated.

I am mostly satisfied with the argument crackers in the Hackerlab C
library and in Systas Scheme -- those might provide some ideas.

As a sort of wildcard, and displaying my ignorance of the details of
the SRFI, I'll point out that what those two crackers have in common
is that they both have a low-level procedural interface (to read
options and arguments one at a time, as if the command line were a
stream of those) and a higher-level declarative interface (to invoke a
small amount of automatic parsing of options and arguments).   The
Emacs "interactive declaration" pattern would seem to be relevent,
too: that pattern is the one where you have a declaration that
converts a user-interface-based input-gathering mechanism into a
regular procedure call, perhaps with some automatic sanity checking of
the input gathered.

"Option arguments must not be optional"
-t

   Old-Return-Path: <xxxxxx@memebeam.com>
   Date: Thu, 26 Sep 2002 10:08:24 -0400 (EDT)
   From: Anthony Carrico <xxxxxx@memebeam.org>
   Content-Type: TEXT/PLAIN; charset=US-ASCII
   Sender: Anthony Carrico <xxxxxx@memebeam.com>
   Resent-From: srfi-37@srfi.schemers.org
   X-Mailing-List: <srfi-37@srfi.schemers.org> archive/latest/17
   X-Loop: srfi-37@srfi.schemers.org
   List-Post: <mailto:srfi-37@srfi.schemers.org>
   List-Help: <mailto:srfi-37xxxxxx@srfi.schemers.org?subject=help>
   List-Subscribe: <mailto:srfi-37xxxxxx@srfi.schemers.org?subject=subscribe>
   List-Unsubscribe: <mailto:srfi-37xxxxxx@srfi.schemers.org?subject=unsubscribe>
   Precedence: list
   Resent-Sender: srfi-37xxxxxx@srfi.schemers.org
   X-UIDL: af0dd686628b39495aa32581c8cfaf5b

   On Thu, 26 Sep 2002, Robert Bruce Findler wrote:

   [....]
     -Anthony Carrico