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