Re: Introducing the no-io branch Lassi Kortela 11 May 2019 07:53 UTC
> I have created a branch of SRFI 170 at < > https://github.com/johnwcowan/srfi-170/tree/no-io> Thank you for this. Interesting to hear what Olin has to say. (Does anyone know of a simple HTML diff program? The git diffs of raw markup are a bit hard to read.) > In addition, the other procedures in this branch no longer accept fds, only > ports and in some cases filenames (which merge things like stat() and > fstat()). Can you list the affacted procedures? I can't find them in git diff. Preliminary comments follow. Port vs fd: - (port->fdes port) -- This procedure is good to have but I would rename it. The arrow is ambiguous: you can't be sure from its name whether it returns an existing fd or creates a new fd (i.e. what dup->fdes does now). - (dup->fdes port fd) -- I would perhaps leave this out. It's useful to provide a direct analog of the Unix (dup2 old-fd new-fd) so it has fds for both arguments. Some ports also don't have fds associated with them (i.e. port->fdes return #f) and it's not obvious from the name what this procedure does in that case. If the user has (dup2 old-fd new-fd) and (port->fdes port) then they can be combined to do what this does now, but the result is more explicit (port->fdes is the only gateway from port-land to fd-land, and you have to call it manually, which I like). - (fdes->textual/binary-input/output-port fd) -- I presume these procedures still cause the underlying fd to be closed when the port is closed. It would most likely be good to have procedures that create ports that don't close the fd. (If somebody else closes the fd and you try to read from the port afterwards, the read would simply be an error. Unix read() probably returns EBADF in that case.) - Taking the above into account: (fdes->port textual? output? close?). Of course there could be more options (e.g. character encoding and newline policy for textual ports) and maybe it's not nice to have so many nameless boolean arguments in a row. - "There is no close-fdes procedure" -- What's the rationale? Spawn: - The process spawning facility can be expected to spawn implementation-specific extensions. (For a taste of the possibilities, see Go and Python, Emacs Lisp start-process function family, and e.g. CLISP's run-shell-command and run-program at <https://clisp.sourceforge.io/impnotes/shell.html>. A good interface would either use keyword arguments, or have the user create a not-yet-launched-process object on which they can set all the options before passing it to a launch procedure. - Allowing the user to set arg0 (i.e. program name) is good. - Allowing user to set subprocess environment (without clobbering the parent's environment with setenv) is good. - on Windows it will have no access to the terminal at all -- might be clearer to use the Windows term "console" here - Python has subprocess.check_call() and subprocess.check_output() and Also the subprocess.CompletedProcess object is good. It has a method check_returncode(): raise a CalledProcessError if the process didn't exit with code zero. Other: - (abort) -- How do we reconcile this with R7RS emergency-exit and similar procedures? Unix itself has abort(), _exit() and exit(). I'm not familiar with simiar Windows functions (other than ExitProcess()). I would also side with usability expert Bruce Tognazzini (asktog.com) that emotionally loaded words like "abort" should be avoided in user interfaces (which APIs are). SIGABRT may be unavoidable; adding an abort function is not. - exec-path-list -- Why is this a variable not a function? As you note, PATH can change in the middle of running the process. If the user wants to save the old path for some reason after changing it themselves, shouldn't they make their own variable to save it?