> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Tuesday, July 28, 2020 5:28 AM
>
> Based on yesterday's threads, how about something like this:
>
> (foreign-error? object) → boolean

If they're nothing more than a property list, and I see no reason to
make them more complicated, the above would be a bit weak, the best it
can do is to make sure it's a plist, or at least a list where you can
use standard procedures to confirm there's an 'error-set key, and its
value is a symbol.

Then again, those *are* the only requirements for a valid error object.

> (make-foreign-error plist...) → ferr
> (raise-foreign-error plist...) → object

The above doesn't return per se....  I currently have it as undefined.

> (raise-continuable-foreign-error plist...) → object
>
> plist is a property list of keys and their values.
>
> (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

How is the user of a Scheme library supposed to know which args he
needs to feed random procedures in the plist??  Message, see below,
can be safely special cased, and maybe some others, but the rest??

> and the resulting values are returned. If the value of the property
> is not a procedure, the value is returned as is and it is an error
> to supply any args.

We could avoid depending on a property list SRFI by dropping the
args argument altogether.  If not, shouldn't the signature be:

(foreign-error-ref ferr property . args) → object

> (foreign-error->string ferr) → string
>
> Return the error message. Perhaps we can have property for a custom
> to-string procedure, and if such a procedure is given in the plist,
> that is used instead of the message.

Given that it is, and always is going to be a message, wouldn't it
be a lot more clear to make the name foreign-error->message?  Does
it make sense to use "->", when this form is always? going to return
a default string??

> As Harold suggested, I have removed all error fields or slots (here
> called properties because we're using the established term "property
> list", but it's the same thing). Typical usage would be:
>
> (define e
>    (make-foreign-error
>     'set 'errno
>     'code 2
>     'symbol 'ENOENT
>     'scheme-procedure 'open-file
>     'foreign-interface 'open
>     'message "open-file called open: errno/ENOENT: No such file or directory"
>     'arguments '("not-a-valid-filename" 0 428)
>     'heritage "SRFI 170"))
>
> (foreign-error-ref e 'set) => 'errno
> (foreign-error-ref e 'code) => 2
> (foreign-error-ref e 'symbol) => 'ENOENT
> (foreign-error->string e) => "open-file called open: errno/ENOENT: No
> such file or directory"

Looks very good modulo my suggestion to swap ->string for [?]message.

However, I'll still repeat my point that we can't make alists/plists
non-reflective, except for opaque values like procedures, and that
however they're constructed, they should have a fixed order, error-set
first, the rest....  Instead of my previous idea of complicating the
whole system by having the symbol that's the value of the error-set
have as its value a list with the order to enforce, any reason to not
have make-foreign-error (always called by the raise- procedures, which
we should explicitly state) put the plist in alphabetical order by key?

Even if there's issues with sort orders not being entirely consistent,
a particular Scheme implementation instantiation should always do it
the same, and that's good enough for my purposes.

> Localizations can be done by giving a procedure instead of a string for
> the 'message property. Then (foreign-error-ref e 'message 'en 'gb) would
> call the message procedure with the arguments ('en 'gb) and that
> procedure should return a string with the right message.

We could define by convention arguments for 'message, but what to do
if it's not a procedure?  Well, we could always just bundle a single
default string into a procedure....  What about being able to discover
what locales it knows or can find out it supports?

- Harold