Go ahead and make all editorial changes unless otherwise noted.
3.4 Processes:
The other two [spawn/spawn-path mode] values cause the procedure to return immediately with an unspecified object.
And that seems to be the case for file-spawn, which may or may not bee a good thing. If it's not a SRFI defined process object, why return anything??
All procedures have to return *something* in Scheme, unless indeed they return zero values. Saying "returns an unspecified object" is standardsese for "returns nothing useful".
Or should we say a bit more about it being system dependent, maybe imply it might be usable for debugging?
Sometimes unspecified objects *are* useful (some Schemes treat `define` as an expression that evaluates to the symbol being defined, as CL does). But no need to say so, as it's inherently implementation-dependent as well as OS-dependent.
It seems to be a major omission to not allow the following process status and manipulation procedures access to the child process when the fork/exec dance allows it, and posix_spawn()/-spawnp() return the child process id through an argument pointer, and if your system doesn't have them, fork/exec.
That's a good point. Bug me about it again later, if you would.
So if a slash character is submitted to spawn-path, it works like spawn? If so, should submitting such raise an error?
Not at all. It's imitating what the shell does.
Both of these procedures may flush buffered output before creating the next process.
Should we strengthen that to "should flush"? Ditto for fork?
Yes.
file-spawn should have something appended to it to make it self-documenting like "-edit" or "-view".
I think that's too much proliferation of procedures. A mode argument makes more sense to me.
Could also be specified to try to use EDITOR or VISUAL, perhaps first, which are mentioned in POSIX in the introduction of a list, "It is unwise to conflict with certain variables that are frequently exported by widely used command interpreters and applications:". With a further recourse to the almost universal "less" and "more" programs. Then "cat" for sure, but that could be impolite, perhaps only allow it if the file is small?
Unix desktops often have some kind of policy file for handling things like this, and I don't want to get snarled up with Gnome vs. KDE etc. etc.
Besides backwards compatibility with scsh, why does fork allow the option of calling a thunk? Requiring passing a thunk through your FFI seems to be an unnecessary burden on new implementations when fork() has no arguments.
The implementation of (fork thunk) can be done mostly at the Scheme level: call the low-level fork, let the parent process return, have the child process call the thunk and then exit. It's very convenient to be able to do things like this in writing concurrent programs. Note that almost all thread systems expect a thunk. It's also true that conventional Posix fork() is essentially (fork thunk) where 'thunk' is the current continuation.
Could, probably should add a kill procedure for process objects/pids....
This has been brought up before: it's signal-process. Probably should mention kill here, as people are apparently confused by it.
3.11 Environment variables, exec-path-list:
This variable contains the contents of the PATH environment variable as a list of strings, where each string contains a single directory pathname.... On Windows, the pathnames are separated by semicolons rather than by colons.
Since it's a list of strings, shouldn't this difference between UNIX based and Windows systems be invisible?
Yes; I'm explaining how to process the PATH variable. The caller does get a list of strings in either case.
3.12 Terminal device control
The seconds time granularity of with-raw-mode is awfully high for human interaction use. Change to milliseconds in the spec, with a note that nothing better than seconds is guaranteed?
Studies show that pauses less than 1 second while typing (or handwriting) are usually for purely physicall reasons like fatigue or writer's cramp. Cognitively meaningful pauses are usually 2 seconds or more.
In the description of open-control-tty, why is SRFI in "If the SRFI process already has a control terminal..."? That's the only use of SRFI qualifying process.
One of my early replace-alls was s/scsh/SRFI/. This one seems to have survived. Just drop "SRFI".
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgIt is revolting to have no better reason for a rule of law than that so it was
laid down in the time of Henry IV. It is still more revolting if the grounds
upon which it was laid down have vanished long since, and the rule simply
persists from blind imitation of the past. --Oliver Wendell Holmes Jr.