Am So., 16. Aug. 2020 um 15:36 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> >> and why it is a must for SRFI 170? What is the problem with SRFI 35
> >> compound conditions, which equally pack various data into an error
> >> object?
>
> I didn't know SRFI 35 existed. How embarrassing!
>
> It's quite a bit more complex, having compound conditions and letting
> the user define new condition types. But a SRFI 35 condition type should
> definitely be one possible implementation of the SRFI 198 foreign-status
> type.
>
> `condition-ref` is just like `foreign-error-ref` and the field system
> works just like the 198 property system. However, each SRFI 35 condition
> type has a particular fixed set of fields whereas much of the point of
> 198 is that the set of properties can evolve and be freely chosen from.

Wouldn't extra fields correspond to SRFI 35 compound conditions? Each
set of extra fields corresponding to each other would become a new
simple condition type packaged with the rest into a compound
condition.