> 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 don't see any problem based on the text of R7RS, and I just confirmed
> Chibi Scheme is happy raising trivial plists.

John confirmed that R7RS can raise any object.

>>>> (foreign-error-ref ferr property args...) → object
>>>>
>>>> property is a symbol. If the value of the property is a procedure,
>>>> that procedure is applied to args
>>
>> The point is that the user of an error object shouldn't have to know
>> which properties in that object have lambdas and which don't. The
>> library writer who makes an error object is responsible for writing any
>> lambdas in such a way that they can be given zero arguments and return a
>> value that is a reasonable value for that property.
>
> Agreed 100% ... but then why have args above?

They should either

1) all be optional args, or

2) be agreed upon in advance (e.g. stated in the error-type registry we
are establishing).

> One good answer: it allows for a very few (for sanity) values like for
> messages to be more sophisticated.  And that can be handled in
> Schemeregistry for anything beyond messages.  Or does this allow us
> us to punt localization for this SRFI??

I agree that there should be a minimum of them.

In theory, if we allow arbitrary lambdas we could punt localization for
this SRFI altogether. However, at this point we've already done the hard
design work for it :) And thankfully, the result is looking like it will
end up fairly simple.

>> If the property value is not a lambda, perhaps we should silently ignore
>> any `args` given by the user. This would make something like
>> `(foreign-error-ref ferr 'message #f)` work even when the message inside
>> the error object is a simple string instead of a lambda.
>
> This requires thought, more than I can muster for the rest of today.  It
> sounds like a generally right approach for this messy ad hoc domain of
> errors.  I can't think of any really bad thing happening.

I'm now confused about that issue as well and my brain isn't producing
anything useful at the moment :D We should sketch some real-world examples.

>> `foreign-error->string`
>
> My conception is that proper full messages are constructed in the plist
> handed to make-foreign-error, so nothing further is required (except of
> course handling multiple of them for localization).

That's my understanding as well.

>> The idea would be to return something suitable for `display` and the
>> like. Suggestions are welcome.
>
> What's more suitable than a simple string?
>
> "open-file called open: errno/ENOENT: No such file or directory"
>
> In my examples the arguments are behind their own key, but a user of
> this SRFI could insert the relevant one(s) in the above message, e.g.:
>
> "open-file called open: errno/ENOENT: No such file or directory "wahFaIh""

For `display` it should definitely be a string, but such a string could
reasonably be returned in many different formats. As a trivial example,
should the error message include a line number or is that too much detail?

If the foreign error object's 'message property does not include a line
number, but there's an extra 'line-number property, then people who want
a more detailed message can use `string-append` and friends to make one.
In general, it's easy to join simple parts together to make a bigger
mess(age), but cutting parts out from a big message is hard - you need
substring search, regexps and the like, and that's a very error-prone
approach.

>> Per the plist definition you found in the Common Lisp
>> HyperSpec, in case of duplicate plist keys the first key wins.
>> `make-foreign-error` should interpret its argument list that way as well.
>
> Indeed.  In the interests of the end user, it *always* produces something
> sensible.  If the plist is malformed, or doesn't include an 'error-set
> key with a symbol as the value, it emits:
>
>   '(errorset error arguments [whatever its argument ere])
>
> The end user should be able to make *some* sense out of this result.
> Error handling tends to be one of the least thoroughly exercised parts
> of a program, I don't want to punish the end user for mistakes with
> error reporting the library implementor made.

Good point. Especially given that Scheme is a dynamic language.