Your last point is the key argument to making the implementation
more complicated than having these be simple record slot getters.

Allowing a lambda for a value gives us a lot more flexibility,
a special case we should not burden the user with.  And there's
a good argument we shouldn't require the user of a foreign
interface to know anything about working with alists, given
our adding lambdas, your optional argument to get the value of a
key is great.

Though a simple display of the whole error object (assuming it's a
record or something else the REPL can grok) won't be as useful if
there's a lambda as a value; here's Chibi Scheme displaying the
'errno example from the SRFI:

{Foreign-Interface-Error #56 errno ((number . 2) (symbol . errno/ENOENT)) open-file open "open-file called open: errno/ENOENT: No such file or directory" ((arguments "not-a-valid-filename" 0 428) (heritage . "SRFI 170"))}

I can look at that and pretty much figure out what I need without
using any of the getters, without even knowing of their existence.

- Harold

----- Original message -----
From: Lassi Kortela <xxxxxx@lassi.io>
Date: Monday, July 27, 2020 3:00 AM

In the current draft:

(make-foreign-error
  '((data . ((arguments . ("not-a-valid-filename" 0 428))
             (heritage . "SRFI 170")))))

(foreign-error:data ferr) → alist or #f

Perhaps this would be useful:

(foreign-error:data ferr) -> return the full alist
(foreign-error:data ferr key) -> return the value for key, or #f

It would let people write things like this:

(foreign-error:data ferr 'sqlstate)
(foreign-error:data ferr 'line-number)
(foreign-error:data ferr 'class-code)

The #f defaults for things that are not provided make it easy to chain
things with (or ...) and the like.

We could further make it so that if the value for key 'foo is a lambda,
then (foreign-error:data ferr 'foo) calls the lambda and returns its
value(s). That would make it possible to lazy-load information that is
expensive to compute.