On Thu, Jun 16, 2005 at 11:33:47PM +0300, Nikodemus Siivola wrote:
> On Sat, 16 Oct 2004, David Lichteblau wrote:
> >However, users typing something like "sbcl -help" tend not to be aware of
> >--end-toplevel-options and are actually trying to find out about the
> >How about renaming "--end-toplevel-options" to something short like "--"
> >making it required before user options?
I don't feel passionately about this one way or the other, but my
mental model of how people are likely to use command line options is
primarily in batch files where concise option names are less valuable
than mnemonic option names, secondarily in one-off interactive things
like "sbcl --userinit /dev/null" where DWIM is an acceptable way to
avoid typing long option names, and only uncommonly in other
I recognize that "--" is conventional in commonly used software
(grep...) to indicate a boundary "terminate command line syntax foo,
commence syntax bar" so it is more mnemonic than it looks. However,
because SBCL itself is implemented in two layers and a user app on top
of it adds a third, we have two boundaries "terminate command line
syntax foo, commence syntax bar" and "terminate syntax bar, commence
syntax bletch" and therefore bare "--" seems a little ambiguous.
> FWIW, -- sounds like good to me, but is quite far from the core of my
> personal desires vrt. command-line processing:
> I would move as much as possible to the lisp-side: I think approximately
> only --core (and --dynamic-space-size ;) need to be handled on the C-side.
> It would probably be a good idea to handle --version too, but rest could
> be moved to lisp, IMO.
That seems to be an orthogonal issue, and sounds reasonable to me.
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C
Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph