RFC: major change to argument processing.

[Rob Browning]

OK, I've been looking in to the possibility of migrating the argument
processing to the Scheme side and, it seems like I might be able to do
that fairly easily, and at the same time, with a little cleverness,
substantially increase the expressiveness of the Meta Switch.  To do
this, though, we would have to be willing to somewhat change the
mostly undocumented bits of how arguments are handled.  If we don't
mind doing that, then I believe this can be done in an almost entirely
transparent manner.

However, I could be way off base here, or I may be sorely
misunderstanding the situation, so I'd like to hear everyone's
comments and criticisms.

Currently, with the meta switch, it looks like you can only specify
one line of arguments, and those arguments are processed without any
"quotification", etc.  This means, for example, that since there's no
shell involved, double quotes, won't do you any good.  Also, with the
current Meta Switch, you can only have one line of arguments.

With respect to quoting, for a normal, non-Meta invocation, the shell
will handle your quotes for you, i.e.

  guile -c "(use-modules (foo bar)) (baz)"

but with the Meta argument, you can't do anything similar.  So you can
say

  #!/usr/bin/guile \
  -e whatever -s
  !#

but you can't (presuming we actually have -x working) say:

  #!/usr/bin/guile \
  -x "(use-modules (srfi srfi-1))"
  -x "(use-modules (srfi srfi-19))"
  -x "(display \"Foo\n\")"
  -e main
  -s
  !#

Now this particular example may be bogus (since these -x arguments
could just be placed as statements in the body), but I'm hoping the
general idea is sound.

So what I'd like to propose is that we switch to processing all of the
contents after the "\" and up to the "!#" using read, with each read
producing one argument.  This would allow you to have as many Meta
Switch lines as you want, and would make it possible for you to have
arguments with whitespace in them using double quotes.  The rules for
processing the arguments would be easy to understand since they're
just the normal read semantics.

Further, unless there are ambiguities (which I can't tell off the top
of my head), we might want to support both strings and raw lists when
appropriate i.e. -x could be written to handle both strings and lists,
so either of these would be appropriate inside the Meta Switch body:

  -x (foo bar)
  -x "(foo bar)"

Switches, like "-x" and "-c" would just be read in as symbols and so
they would be easy to detect and handle.

If we do decide this is an acceptable approach, I think we'd be able
to use the exact same scheme side argument parser for both normal args
and the meta-switch args with no more than some minor massaging of the
input (i.e. calling string->symbol on all non-Meta Switch args that
come in with a leading "-", or similar...)

Thoughts?

(If this is acceptable, I'm thinking of doing it immediately, so that,
 if it works and is stable enough, we can have it and "-x" for 1.6.)

Thanks
 
-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930