Email list hosting service & mailing list manager

Should we create a general "systems errors" SRFI? hga@xxxxxx (19 Sep 2019 13:27 UTC)
Re: Should we create a general "systems errors" SRFI? Lassi Kortela (19 Sep 2019 13:34 UTC)
Re: Should we create a general "systems errors" SRFI? John Cowan (19 Sep 2019 20:26 UTC)
Re: Should we create a general "systems errors" SRFI? Lassi Kortela (19 Sep 2019 20:54 UTC)
Re: Should we create a general "systems errors" SRFI? John Cowan (19 Sep 2019 21:04 UTC)
Re: Should we create a general "systems errors" SRFI? Lassi Kortela (19 Sep 2019 21:21 UTC)
Re: Should we create a general "systems errors" SRFI? hga@xxxxxx (19 Sep 2019 21:23 UTC)
Re: Should we create a general "systems errors" SRFI? Lassi Kortela (19 Sep 2019 21:32 UTC)
Re: Should we create a general "systems errors" SRFI? hga@xxxxxx (19 Sep 2019 22:12 UTC)
Re: Should we create a general "systems errors" SRFI? Lassi Kortela (20 Sep 2019 10:37 UTC)
Re: Should we create a general "systems errors" SRFI? John Cowan (20 Sep 2019 11:27 UTC)

Re: Should we create a general "systems errors" SRFI? Lassi Kortela 19 Sep 2019 21:21 UTC

>> The pet feature I'd like to have is retrieving errno values from
>> standard RnRS I/O procedures;
>
> I'm not opposed in principle.  However, this will have to hook deeply into
> the Scheme implementation, and implementers will tend to resist things that
> do that, especially for implementations that care a great deal about
> backward compat.
The nice thing is that we can make this optional, so Schemes
implementing the SRFI can adopt it piecemeal or not at all. Any
exception e from (open-input-file "nonexistent") would be free to answer
(os-error? e) => #f in case the implementation doesn't expose the errno.

This also means that a pure-Scheme implementation of the SRFI can be
imported into Schemes with no native support, in case some FFI library
needs the SRFI to report its OS errors.