On Sat, May 11, 2019 at 3:53 AM Lassi Kortela <xxxxxx@lassi.io> wrote:
 
Thank you for this. Interesting to hear what Olin has to say.

I doubt we'll hear from him.
 
> 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.

They are set-file-{mode,owner,group}, sync-file, truncate-file, file-info, and the tty procedures.
 
- (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).

Good point.  I've changed it to port-fdes, as if it were an accessor.

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 [dup->fdes] 
procedure does in that case.

An error, surely.
 
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).

But is there any use for the dup2 part separately?  If not, they may as
well be combined.
 
It would most likely be good to have procedures that create 
ports that don't close the fd.

I think that would be asking for trouble.  The model here is that you know you need to read characters from fd 3 when you start up, so you call (fdes->textual-input-port 3) and just use that port from now on.

But if you really need a fd you control completely, then single-argument dup->fdes makes sense, so I've added that option back.  We want to avoid sharing fds between ports and other uses as much as possible, I think.

- 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.

See <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/FilesAdvancedCowan.md> for the approach I'm recommending for open-flags.  I think settings lists are a better idea than keyword arguments, and they are completely portable and quite easy to use in connection with quasiquote and a suitable destructuring macro
 
- "There is no close-fdes procedure" -- What's the rationale?

You're looking at the section that explains the differences between the SRFI and Scsh.  Scsh doesn't need close-fdes, because its version of close-port does it all.

- The process spawning facility can be expected to spawn
implementation-specific extensions.

This is just the basics.  I expect there will be higher-level SRFIs as well.
 
- (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.

Okay.  It came from Python and ANSI C, but I'm not wedded to it, so it's gone again.

- exec-path-list -- Why is this a variable not a function? As you note,
PATH can change in the middle of running the process.

Though this SRFI does not provide means for tampering with your own process environment, the effects of which are in general less than predictable.  Putenv can fail if there's no room in the standard location for the environment to put the new value.

Scsh's exec procedures look at this variable rather than PATH itself, implying that it does its own path lookups rather than relying on libc.  I'm not sure how I feel about that.


John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
If I have seen farther than others, it is because they are closer than I am. --Noetica
Noetica’s standing on the shoulders of galahs.  --Gibbon
Better than standing on the shoulders of hobyahs (not to be confused
with hobbits, though some have done so).  --me