> In words that mostly have a small number of letters:    :-)

:D Once again, this just goes to show that "We can solve any problem by
introducing an extra level of indirection."

(Obligatory link to <http://www.lysator.liu.se/c/pikestyle.html> and
"variables whose names are small essays on their use".)

> If you call foreign-*-ref and the value in the slot is not a procedure,
> you get it.  If it is a lambda, the lambda is called, maybe with arguments.
>
> But what if you want the lambda itself?  You need another way to get that.
>
> My idea is to use a second standard procedure to fetch the lambda rather
> than calling it.  If used on a non-procedure slot, fake a lambda
> instead.  But an error would work too.

That's a reasonable idea. I would solve that by requiring the people who
put lambdas in foreign-error objects to wrap their lambdas themselves.

The end result from both approaches is that the consumer of the error
object doesn't need to care which values are lambdas and which are not.

> (How about foreign-ref, make-foreign, etc. etc.?)

Names as short as that would be fantastic, but lamentably they only
really work in small systems like Forth. Once you have two different
kinds of foreign things, it becomes hard to disambiguate. Of course, in
a Scheme library you can choose to only import some of the other
libraries from a big system, but in practice people do tend to get
exposed to many of them over time.

Following the R6RS ampersand convention, &foreign would seem as good as
the standard &warning or &assertion. But I think the ampersand is only
used for the condition type itself, not for accessors. For example:

cond type: &i/o-invalid-position
procedure: (make-i/o-invalid-position-error position)
procedure: (i/o-invalid-position-error? obj)
procedure: (i/o-error-position condition)

Following that example we would have:

cond type: &foreign
procedure: (make-foreign-something . plist)
procedure: (foreign-something? obj)
procedure: (foreign-something-ref condition property . args)

It's actually very good that this discussion is forcing us to peruse
R6RS conditions and design something that's in harmony with them.