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.