From: John Cowan <xxxxxx@ccil.org>
Date: Sunday, October 06, 2019 2:53 PM
Are we still planning on breaking all this out to a separate "system errors" SRFI? Besides our using POSIX errnos for our own error reporting such as bad arguments, I want another string to indicate where the error occurred, e.g. which argument is bad.
That can be put into the irritants (aka "data"). These error objects are exactly parallel to the R6RS (not SRFI 23 / R7RS) error call, with the procname playing the role of "who". For backward compat reasons WG1 decided not to go with this style for `error`, but it definitely has its merits.
So any optional data like "where the error happened" should be passed as irritants, and conventions need to be established and mentioned in the error SRFI so people know to look for them. Which I remembered must be a separate SRFI, if for no other reason than to share between 170 and the processes SRFI, if it is not subsumed by the grand system errors SRFI Lassi and I are planning.
If fitted into that, it would have, say, a POS or PSX id string (this is inspired by Oracle's very useful prefixing "ORA-" to all its errors) ... but the "code" is interesting, because the integers for errnos can be different on different systems. As an irritant of its own, POSIX errnos are integers, but e.g. PostgreSQL error codes are alphanumeric. That could be a useful way to partition errnos from calling the system vs. our own internal error raising, prefix ours with a alphabetic character so they can never overlap.
There are 9 commits you can first pick up from the official master, a couple which change the HTML file, and my addition of the Chibi Scheme example implementation, which:
Done. Should I be merging your chibi-scheme-implementation branch as well?
I just deleted it, it was crafted to merge cleanly with Arthur's master, which he did a while ago.
- Harold