> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Thursday, September 19, 2019 4:32 PM
>
>> This is good, since I'm mentally budgeted one calendar year for my
>> DBI/DBD API and perhaps something on top of it.
>
> Very nice :) I wish I had your and John's ability to dedicate myself
> to something.

Yeah, you do like to bounce around a lot.  Me, when I finally decide to
sink my teeth into something (and that can take years), I can work on it
non-stop for months and months.

>> Since getting one's error signaling regime nailed down is one of the
>> very first parts of such a project, I've already been walking this
>> path with SRFI 170, and I suggested the idea ^_^, I'll be delighted
>> to work with Lassi to nail this down.
>
> Great! Do you want to write the first draft or should I? Design work
> should of course be constantly ongoing as we think of new stuff, but
> documents tend to be more coherent if one person at a time is writing :)

For now, why don't we both put it on our task list, and if one of us
feels like making the first draft, email the other to old-fashioned
"check out" that task.

First, though, we should start publicly collecting desiderata.  Offhand:

As previously mentioned, it should be a union of "system errors", which
I define to be stuff in the stack that the Scheme system sits on or uses
(this *might* include a Boehm GC library), and errors library writers
need to signal when using system code.  I.e. making a simple test and
raising an error instead of handing it to an FFI which will segfault.

(Optional) indication of where the error happened!!!  Not just what
procedure, but allow for a Scheme to insert a file name and line number,
or the user to say "That port you think you gave me?  It isn't a
port....", that is, a string that can be searched on.  A scheme like
the one below could also provide the same thing if not for the cut
and paste disease:

As previously discussed, we can use a short abbreviation to make the
source of error codes more obviously, like Oracle's "ORA-".

- Harold