Email list hosting service & mailing list manager

Command-line-parameter access John David Stone (09 Mar 2001 16:47 UTC)
Re: Command-line-parameter access sperber@xxxxxx (20 Mar 2001 10:36 UTC)

Command-line-parameter access John David Stone 09 Mar 2001 16:46 UTC

        I'd like to suggest a change in the semantics section, replacing
the sentence

    scheme-script calls this procedure with one argument, a list of the
    remaining Unix command-line arguments.

with

    scheme-script calls this procedure with the remaining Unix command-line
    arguments, each passed to the procedure as a string value.

        For instance, if the file foo.ss contains the code

            (define (foo arg)
              (write arg)
              (newline))

I'd like the command `scheme-script --r5rs foo.ss --call foo bar' to
produce the output

            "bar"

rather than

            ("bar")

and if the file baz.ss contains the code

            (define (baz . arguments)
              (for-each display arguments)
              (newline))

I'd like the command `scheme-script --r5rs baz.ss --call baz quux' to
produce the output

            quux

and the command `scheme-script --r5rs baz.ss --call baz 5e1 car \"foo\"'
to produce the output

            5e1car"foo"

and not something like

            50.0#<procedure car>foo

        The key features of this design are:

        (1) The Scheme programmer can choose to accept any number of
command-line arguments (by using variable arity in the entry-point
procedure), or she can choose to impose a restriction.  Under the original
design, the entry-point procedure has to accept all of the command-line
arguments and has to accept them bundled as a list.

        (2) Most Unix shells impose constraints on the syntax of
command-line arguments that are difficult or impossible to reconcile with
the full syntax of Scheme literals, let alone Scheme expressions.  Passing
all command-line arguments to the entry-point procedure as strings
minimizes the number and complexity of the conflicts, allocating to the
shell the responsibility for performing or preventing wild-card expansion,
recognizing escapes for the shell comment character, and so on, and
allocating to the Scheme program the responsibility for parsing strings to
recover non-string values (for instance, in the most common case, invoking
string->number).

        I have not addressed the problem of collisions between shell syntax
and the syntax of the Scheme identifier for the entry-point procedure.
It seems to me that the identifier should be the result of shell
pre-processing rather than literally what appears in the command line, in
cases where these differ, but I don't know how to say this without making a
lot of possibly unwarranted assumptions about what shells can and can't do.

        In the Example section, the Unix cat utility would look like this
if my suggestion is adopted:

            #!/bin/sh
            IFS=" "
            exec scheme-script -r5rs "$0" -call cat "$@"
            !#
            (define (cat . arguments)
              (for-each display-file arguments))

            (define (display-file filename)
              (call-with-input-file filename
                (lambda (port)
                  (let loop ()
                    (let ((thing (read-char port)))
                      (if (not (eof-object? thing))
                          (begin
                            (write-char thing)
                            (loop))))))))

Incidentally, `argument' in the sixth line of the example in the draft SRFI
should be changed to `arguments' whether or not my suggestion is adopted.

--
   John David Stone - Lecturer in Computer Science and Philosophy
           Manager of the Mathematics Local-Area Network
           Grinnell College - Grinnell, Iowa 50112 - USA
     xxxxxx@cs.grinnell.edu - http://www.cs.grinnell.edu/~stone/