> I have only partially been able to follow your discussions and the
> development of SRFI 198, so what I am saying is as a bystander (and
> maybe a too uniformed one):

No worries :) It has been very verbose. Thanks for participating anyway!

> Could it be that the problem you want to solve with SRFI 198 isn't yet
> clearly determined?

Yes - that's basically the root cause of all our problems.

I think the problem is necessarily hard to predict. We can either design
one interface that is extremely generic, or many (a dozen?) interfaces,
each quite specific, all of which satisfy a smaller generic interface.

I believe that we should design a fully generic interface right away,
because we'll be in only a slightly better position to design specific
ones later. It seems there are so many foreign libraries and servers
that we'll never be able plan more than one or two moves ahead.

> Let's take a step back. Apparently, you want to solve two things at
> least: (1) Having a distinct predicate for foreign status. (2) Having
> error objects that carry an extensible list of properties.
>
> I wonder whether it will help to abstract things a bit more. (1) can
> be solved independently of (2). Or, spoken differently, for other
> kinds of error objects (like file errors or read errors) it also makes
> sense to have such an extensible list of properties.
>
> SRFI 198 is not meant to be based on the condition system of the R6RS,
> but I think it helps a lot to ponder about how SRFI 198 would be
> implemented on that condition system (see
> https://www.gnu.org/software/guile/manual/html_node/rnrs-conditions.html,
> for example. Or SRFI 35.).

198 should definitely be made easy to do in the R6RS condition system.

> In this system, it makes sense that being a foreign status is
> implemented as a simple condition. And the association list could go
> its own condition type (as in &irritants). Raising a foreign status
> together with the association list would mean to raise a compound
> condition. This way, the association list condition could also be used
> for other types of conditions like I/O conditions.
>
> The question that has to be answered then is how certain keys will
> interact with other condition types. For example, it is conceivable to
> have a condition type &errno which should somehow be related to an
> errno key in a general association list.
>
> This is very much related to your latest discussion about organizing
> the foreign statuses in some kind of hierarchy. As I guess that you
> intend SRFI 198 to be naturally implementable on R6RS as well, I am
> sure it will be helpful to conceive an implementation on top of its
> condition that integrates naturally and that this will help to
> understand the actual SRFI 198 better.

The problem with compound conditions is that they are not very
universal. Mainly R6RS (and Racket?) has them. There's also SRFI 35
(Conditions) but it requires each condition to be an instance of a type
with a set of fields defined ahead of time. (Probably most condition
systems build into programming languages do that.)

Another problem with fitting 198 into the R6RS condition system is that
not all foreign statuses are errors. R6RS has &error and &condition
types; some 198 status objects would naturally be a subtype of &error
(e.g. HTTP 404 Not Found) but other would not (e.g. HTTP 200 OK).

We should probably make 198 objects be subtypes of &condition, which is
always correct, but with the unintuitive result that errors are not a
subtype of &error. Or we could make it a subtype of &error, with the
misleading result that some successful results are a subtype of &error.

Or we could have two separate constructors: `make-foreign-status` and
`make-foreign-error`. They would make an identical object, except the
first makes a subtype of &condition and the second &error. That may be best.