[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Command-line-parameter access

This page is part of the web mail archives of SRFI 22 from before July 7th, 2015. The new archives for SRFI 22 contain all messages, not just those from before July 7th, 2015.



        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
     stone@xxxxxxxxxxxxxxx - http://www.cs.grinnell.edu/~stone/