>> 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.
>
> And here's the decisive argument against requiring bare plists.
> Abstract data type it is, if you so choose.

Seconded - this is a perfect example.

I was also thinking of porting the foreign error interface Common Lisp,
Emacs Lisp and Clojure. There's already at least one Japanese guy
porting SRFIs to CL: <https://github.com/g000001>.

Harold, you are in good company -- even RMS advocated using concrete
data types instead of ADTs in Emacs Lisp so preferring ADTs is not
obvious even to luminaries. IIRC Paul Graham also preferred concrete ones.

In my experience, time and time again ADTs produce better results in
long-lived APIs. That's counter-intuitive since programmers are told to
keep things simple and concrete types seem simpler. But an ADT is a
simpler _interface_ (i.e. abstraction) since it has fewer parts that
don't deal directly with the problem.

Garbage collection is pretty much the mother of all abstractions, and
it's the biggest revolution in the field since structured programming.
Immutable data pure functions are another. Long-term progress is often
enabled by more restrictive tools, not less.