posix-error and a list of scheme procedure arguments Shiro Kawai 15 Aug 2020 07:54 UTC
Re: posix-error and a list of scheme procedure arguments hga@xxxxxx 15 Aug 2020 10:57 UTC
Re: posix-error and a list of scheme procedure arguments Marc Nieper-Wißkirchen 15 Aug 2020 11:16 UTC
Re: posix-error and a list of scheme procedure arguments hga@xxxxxx 15 Aug 2020 11:50 UTC
Re: posix-error and a list of scheme procedure arguments Lassi Kortela 15 Aug 2020 12:09 UTC
Re: posix-error and a list of scheme procedure arguments hga@xxxxxx 15 Aug 2020 12:42 UTC
Synthetic errno values Lassi Kortela 15 Aug 2020 13:10 UTC
Re: Synthetic errno values John Cowan 15 Aug 2020 15:19 UTC
Re: Synthetic errno values Lassi Kortela 15 Aug 2020 15:34 UTC
Re: Synthetic errno values hga@xxxxxx 15 Aug 2020 16:02 UTC
Re: Synthetic errno values Lassi Kortela 16 Aug 2020 07:58 UTC
Re: Synthetic errno values hga@xxxxxx 16 Aug 2020 12:39 UTC
Re: Synthetic errno values Lassi Kortela 16 Aug 2020 13:07 UTC
Re: posix-error and a list of scheme procedure arguments Shiro Kawai 16 Aug 2020 01:11 UTC
Re: posix-error and a list of scheme procedure arguments hga@xxxxxx 16 Aug 2020 02:26 UTC
Re: posix-error and a list of scheme procedure arguments Shiro Kawai 16 Aug 2020 02:30 UTC
Split SRFI 198 from generic debugging/inspection? hga@xxxxxx 16 Aug 2020 02:43 UTC
Re: Split SRFI 198 from generic debugging/inspection? Lassi Kortela 16 Aug 2020 09:06 UTC
Re: Split SRFI 198 from generic debugging/inspection? hga@xxxxxx 16 Aug 2020 13:01 UTC
Matching what other languages give in SRFI 170 errors Lassi Kortela 16 Aug 2020 13:47 UTC
Re: Matching what other languages give in SRFI 170 errors Marc Nieper-Wißkirchen 17 Aug 2020 06:11 UTC
Re: Matching what other languages give in SRFI 170 errors Lassi Kortela 17 Aug 2020 10:10 UTC
Re: posix-error and a list of scheme procedure arguments Göran Weinholt 16 Aug 2020 08:52 UTC
Re: posix-error and a list of scheme procedure arguments Lassi Kortela 16 Aug 2020 09:01 UTC
Re: posix-error and a list of scheme procedure arguments Shiro Kawai 16 Aug 2020 09:10 UTC
Re: posix-error and a list of scheme procedure arguments Göran Weinholt 16 Aug 2020 09:40 UTC
Re: posix-error and a list of scheme procedure arguments Marc Nieper-Wißkirchen 16 Aug 2020 10:20 UTC
Re: posix-error and a list of scheme procedure arguments Shiro Kawai 16 Aug 2020 11:29 UTC
Re: posix-error and a list of scheme procedure arguments Marc Nieper-Wißkirchen 16 Aug 2020 12:18 UTC
Continuation marks and SRFI 198 Lassi Kortela 16 Aug 2020 11:29 UTC
Re: Continuation marks and SRFI 198 Marc Nieper-Wißkirchen 16 Aug 2020 12:51 UTC
Re: posix-error and a list of scheme procedure arguments Shiro Kawai 16 Aug 2020 11:17 UTC
Passing symbols to say where errors came from? Lassi Kortela 16 Aug 2020 11:21 UTC
Re: Passing symbols to say where errors came from? John Cowan 17 Aug 2020 17:06 UTC
Re: Passing symbols to say where errors came from? hga@xxxxxx 17 Aug 2020 18:43 UTC
Re: Passing symbols to say where errors came from? Shiro Kawai 17 Aug 2020 22:05 UTC
Re: Passing symbols to say where errors came from? Marc Nieper-Wißkirchen 18 Aug 2020 06:09 UTC

Re: posix-error and a list of scheme procedure arguments Lassi Kortela 16 Aug 2020 09:01 UTC

>> I can certainly wrap Gauche's low-level syscall API with guard and
>> translate <system-error> to srfi-170 error, in every srfi-170 API. The
>> overhead isn't small and I'd rather avoid it if I can.
>
> Loko Scheme's implementation of SRFI 198 uses the R6RS condition system.
> This way there is no need to use guard, because any syscall error
> anywhere in Loko already raises an R6RS condition and SRFI 198 just
> needs to recognize it. Maybe you can use a similar strategy in Gauche,
> can you teach SRFI 198 to understand <system-error>?
>
> In Loko, the foreign-error:* procedures understand R6RS conditions and
> check their argument to see which kind of condition they've been given.
> make-foreign-error translates its argument into conditions. This also
> has the benefit of letting any R6RS code handle the &who, &message and
> &irritants part of the SRFI 198 error.
>
> It works because SRFI 198 defines a constructor and accessors that hide
> the concrete type of conditions. I haven't been keeping up with the
> discussion lately, but I hope that this aspect hasn't changed.

Great! This is exactly the kind of implementation I was hoping the
abstract data type would enable. I recommend the same for Gauche as
well. I also did a Common Lisp port using the same principle.

If needed, an ADT can also have multiple implementations, e.g. one based
on a native condition type and another based on a record type. The
`foreign-status?` predicate and `foreign-status-ref` accessor will just
have to be written to recognize both. Gauche has generic functions that
can handle this if needed.