> As I've commented to the point of belaboring, I'm thinking for this
> API it would be best if we skip an abstract data type in favor of a
> transparent unwrapped plist, keys ordered by make-foreign-error, so
> that a human in a REPL without even a pretty printer can make sense of
> it. The only thing I see an abstract data type gaining us is an
> absolutely certain version of foreign-error?, and I don't think that's
> worth the loss in easy transparency.
I have to disagree here. Interfaces in SRFIs are generally (though not
always) specified using abstract data types to give more leeway to
implementors to find suitable representations in many different situations.
That means a plist (ideally with a magic object tested for `eq?`) is one
possible representation, but a record type or an instance of a class (in
Schemes with an object system) is another. It gives more possibilities
to tie foreign errors cleanly into existing condition systems.
I might've missed the context but Harold suggested foreign error conditions to be a bare plist?
Some Scheme implementations already have specific foreign library interfaces that raise specific conditions on error, and srfi-198 needs to be adopted in such systems. Gauche raises <system-error> condition on POSIX errors. Even some Scheme wrappers raise <system-error> when it's emulating some POSIX functionalities. I'd like the foreign error conditions are abstract enough so that I can make <system-error> or other existing conditions "pretend" to be one.