>>> Thus we have incompatible visions for SRFI 198. I haven't noticed a disagreement about the overall vision, just details. I feel we want the same kind of end result but conceptualize the details differently. My main concern is that I have a poor track record of predicting the future, as do most other people. Therefore I'd like to keep the interface minimal and avoid coupling any two things that don't need to be coupled: - If a property can be optional, it should be. - If a property can be independent of another property, it should be. - Missing properties should have #f defaults, a time-tested approach. > Ditto for the collections used as inputs, and output for > foreign-status-plist/alist/whatever. Shall we stick with alists, move > to plists, and for make-foreign-status and raise-foreign-error, > require one of those two, or just have the key/value pairs be optional > arguments, e.g. (raise-foreign-error 'set 'generic-c-lib 'subset > 'libsodium etc.). I'm confident we'll figure out the interface if we can only figure out the properties. Thankfully the more exotic properties can be added later; they don't need to be ready to get the SRFI finalized. >> 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. Implementing 198 using 35, one of the fields in the condition object would have to be a plist (or alist or hash-table) to house all the non-standard properties. Thus, SRFI 35 `condition-ref` is not a drop-in replacement for 198 `foreign-status-ref`.
