Re: R6RS condition type hierarchy

Show/hide message thread

raise-foreign-error Marc Nieper-Wißkirchen (16 Aug 2020 14:30 UTC)

Re: raise-foreign-error hga@xxxxxx (16 Aug 2020 15:04 UTC)

Re: raise-foreign-error Marc Nieper-Wißkirchen (16 Aug 2020 15:26 UTC)

Re: raise-foreign-error hga@xxxxxx (16 Aug 2020 16:02 UTC)

Re: raise-foreign-error John Cowan (17 Aug 2020 02:35 UTC)

Re: raise-foreign-error hga@xxxxxx (17 Aug 2020 11:58 UTC)

Re: raise-foreign-error Lassi Kortela (17 Aug 2020 12:06 UTC)

Re: raise-foreign-error hga@xxxxxx (17 Aug 2020 14:20 UTC)

R6RS condition type hierarchy Lassi Kortela (17 Aug 2020 12:10 UTC)

Re: R6RS condition type hierarchy John Cowan (17 Aug 2020 13:40 UTC)

Re: R6RS condition type hierarchy Lassi Kortela (17 Aug 2020 14:47 UTC)

Re: R6RS condition type hierarchy Marc Nieper-Wißkirchen (17 Aug 2020 14:56 UTC)

Re: R6RS condition type hierarchy Marc Nieper-WiÃkirchen 17 Aug 2020 14:56 UTC

It also makes sense to have a condition type &errno, which just
packages the errno symbol.

Am Mo., 17. Aug. 2020 um 16:48 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> We could have &foreign (a subtype of &condition) and &foreign-error (a
> subtype of &error) separately, and `foreign-status?` would test for
> either of those. It's a bit iffy, but could be worse?

We also have the I/O errors in section 8.1 of the R6RS Standard
Library report. I guess it makes sense to do some merging here as
well.