> 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.

There's a benefit even for people who are well versed in using alists: a
`(foreign-error:data ferr key)` procedure can easily return `#f` when
the key is not present, but using RnRS `assoc` is clumsy in that case:

(let ((value (let ((pair (assoc 'key (foreign-error:data ferr))))
                (if pair (cdr pair) #f))))
   ...use the value...)

vs

(let ((value (foreign-error:data ferr 'key)))
   ...use the value...)

GNU Emacs and XEmacs had a somewhat famous falling-out regarding whether
to use abstract data types (opaque object with a public interface) or
transparent data types (make everything out of alists and expose the
list structure as an officially supported interface). IMHO XEmacs won
that debate -- their APIs were nicer. XEmacs didn't win mindshare, but
that's another matter :)

> 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.

That output is indeed very convenient. But in general, SRFI 198 errors
are opaque objects - a record type is just one permitted implementation
strategy (at least this was my impression). It would help if Scheme had
custom printers for user-defined data types like Common Lisp's
`print-object`; probably someday.

As long as we rely on a generic record-type printer, it's necessarily at
odds with lambdas that lazy-load error information. I would vote to have
the lambdas since information-rich error objects are nice but loading
all that information every time (error message localizations, detailed
info about the location of the error, etc.) is wasteful.