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)
|
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.