SRFI 198: clear enough for next draft? Lassi Kortela (02 Aug 2020 11:35 UTC)
Re: SRFI 198: clear enough for next draft? hga@xxxxxx (02 Aug 2020 12:22 UTC)
Re: SRFI 198: clear enough for next draft? Lassi Kortela (02 Aug 2020 13:21 UTC)
Re: SRFI 198: clear enough for next draft? hga@xxxxxx (02 Aug 2020 15:04 UTC)
Re: SRFI 198: clear enough for next draft? John Cowan (06 Aug 2020 03:49 UTC)
Re: SRFI 198: clear enough for next draft? hga@xxxxxx (12 Aug 2020 16:56 UTC)
Re: SRFI 198: clear enough for next draft? John Cowan (06 Aug 2020 03:22 UTC)
Re: SRFI 198: clear enough for next draft? hga@xxxxxx (12 Aug 2020 16:33 UTC)
Re: SRFI 198: clear enough for next draft? John Cowan (05 Aug 2020 06:13 UTC)
Re: SRFI 198: clear enough for next draft? hga@xxxxxx (05 Aug 2020 13:11 UTC)
Re: SRFI 198: clear enough for next draft? Lassi Kortela (05 Aug 2020 15:23 UTC)
Re: SRFI 198: clear enough for next draft? hga@xxxxxx (05 Aug 2020 15:59 UTC)
Re: SRFI 198: clear enough for next draft? Lassi Kortela (05 Aug 2020 16:17 UTC)

SRFI 198: clear enough for next draft? Lassi Kortela 02 Aug 2020 11:35 UTC

Are we settled on something like the following so far?

The foreign-error type is an abstract data type (ADT).

(foreign-error? object) => boolean

(foreign-error-ref ferr symbol) => object

(make-foreign-error . plist) => ferr

(raise-foreign-error . plist)

- Plist keys should be symbols.

- Need to decide whether keyword objects are also accepted and converted
to symbols internally.

- Specify what to do in case of duplicate plist keys (after normalizing
them all to symbols). First one wins?

Do we need a `raise-foreign-error` in the SRFI? (raise
(make-foreign-error ...)) is not substantially more difficult.