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/