[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I'd like to suggest a change in the semantics section, replacing
scheme-script calls this procedure with one argument, a list of the
remaining Unix command-line arguments.
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)
I'd like the command `scheme-script --r5rs foo.ss --call foo bar' to
produce the output
and if the file baz.ss contains the code
(define (baz . arguments)
(for-each display arguments)
I'd like the command `scheme-script --r5rs baz.ss --call baz quux' to
produce the output
and the command `scheme-script --r5rs baz.ss --call baz 5e1 car \"foo\"'
to produce the output
and not something like
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
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:
exec scheme-script -r5rs "$0" -call cat "$@"
(define (cat . arguments)
(for-each display-file arguments))
(define (display-file filename)
(let loop ()
(let ((thing (read-char port)))
(if (not (eof-object? thing))
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/