Command-line-parameter access

[John David Stone]

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.

[sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])]

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

We've chosen to adopt the string part (sloppy wording on our part),
but pass on the change in parameter passing, mainly because it would
require us to say something about error checking in that case.