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?

The trickiest part to implement so far has been real-path, and that
actually needs more testing. I think most implementers will rely on an
existing version of real-path that comes from their host environment.
That would usually be realpath(3) from libc, but not everyone will have
access to that function. (No need to take any action on this, I just
wanted to mention it).

One thing I don't understand is the errno-error stuff. 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.

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

Regards,

--
Göran Weinholt
https://weinholt.se/