Email list hosting service & mailing list manager

Loko has (some?) srfi-170 support Duy Nguyen (02 Oct 2019 08:08 UTC)
Re: Loko has (some?) srfi-170 support Göran Weinholt (06 Oct 2019 07:20 UTC)
Re: Loko has (some?) srfi-170 support hga@xxxxxx (06 Oct 2019 11:16 UTC)
Re: Loko has (some?) srfi-170 support John Cowan (06 Oct 2019 15:07 UTC)
Re: Loko has (some?) srfi-170 support hga@xxxxxx (06 Oct 2019 15:39 UTC)
Re: Loko has (some?) srfi-170 support John Cowan (06 Oct 2019 19:53 UTC)
Error handling in SRFI 170 and other SRFIs hga@xxxxxx (06 Oct 2019 21:41 UTC)

Re: Loko has (some?) srfi-170 support hga@xxxxxx 06 Oct 2019 11:16 UTC

> From: "Göran Weinholt" <>
> Date: Sunday, October 06, 2019 2:20 AM
> Duy Nguyen <> 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]
> 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

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