> From: "Göran Weinholt" <xxxxxx@weinholt.se>
> Date: Sunday, October 06, 2019 2:20 AM
>
> Duy Nguyen <xxxxxx@gmail.com> writes:
>
>> I haven't seen it mentioned yet, but here's a quote from loko
>> scheme [1]
>>
>>> ... and there’s an early POSIX library for the Linux port based on
>>> the current SRFI 170 draft.
>>
>> [1] https://weinholt.se/articles/new-r6rs-compiler/
>
> Yes, there's a partial implementation in lib/posix.sls based on draft
> #6. I took a break before finishing the whole implementation, partly
> because I wasn't sure what in the draft was going to be changed later.
> IIRC there was some discussion about moving out processes?

Processes, including anything having to do with other processes except
create-fifo, file-info-fifo?, parent-pid, and process-group, have been
removed for a future SRFI.

While not quite "official", right now the most up to date version of
SRFI 170 can be found at https://github.com/hga/srfi-170.

> [ real-path. ]
>
> One thing I don't understand is the errno-error stuff.

It's planned to be replaced with a new SRFI that handles "system"
errors, which will include things like error reporting from databases.
Lassi and I are taking point on this.

> Why does it take a procedure object? Several of the procedures in SRFI
> 170 do not map directly to any particular POSIX function or syscall,
> so I doubt you could use this mechanism to figure out the true context
> of the errno exception.

That's one of the reasons, for example I overload errno/inval in these
cases in my Chibi Scheme example implementation, and there can be more
than one source of this as I check arguments for sanity.

>| (errno-error errno procedure . data)  →  never returns     (procedure)
>|
>|   Raises a non-continuable exception for POSIX error number errno. The
>|   procedure and data arguments are packaged up in the exception packet
>|   passed to the exception handler. It is an error to pass an errno
>|   that is not provided by the OS.
>
> My suggestion is that this procedure should take the name of the failed
> syscall or POSIX function (depending on which the implementer used). At
> least then you can look up the errno code in the manpages.

That's one of the first changes I want to make, as well as providing an
easy mapping from errno number to its name.

- Harold