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.