https://htmlpreview.github.io/?https://raw.githubusercontent.com/hga/srfi-198/master/srfi-198.html

For each release:

 * Fix errors reported by W3C HTML Validator.
 * Fix spelling.

Check out the new .css.

----------------

Add this text from Marc for the raise procedure:

(A) In an R6RS or R7RS system or in a system support SRFI 18, raising
an exception means to call "raise" on the exception.
(B) In a system just supporting SRFI 23, raising an exception means
calling "error" with "message" and "irritants" as follows: ...

----------------

Add a severity key/value pair?

----------------

From: Lassi Kortela <lassi@lassi.io>
Message-ID: <ade30446-0836-5577-fc9c-35433e39af1a@lassi.io>
Date: Tue, 28 Jul 2020 16:02:49 +0300

The following is a full sample implementation of the SRFI with the
changes discussed in this thread. There are probably subtle bugs. I left
out `raise-continuable-foreign-error` and `foreign-error->string`.

(define-library (srfi 198)
   (export make-foreign-error raise-foreign-error
           foreign-error? foreign-error-ref)
   (import (scheme base) (srfi 69))
   (begin

     (define-record-type foreign-error
       (%make-foreign-error table)
       foreign-error?
       (table %foreign-error-table))

     (define (make-foreign-error . plist)
       (let ((table (make-hash-table)))
         (let loop ((tail plist))
           (cond ((null? tail)
                  (%make-foreign-error table))
                 ((and (pair? tail) (symbol? (car tail)) (pair? (cdr tail)))
                  (hash-table-set! table (car tail) (cadr tail))
                  (loop (cddr tail)))
                 (else (error "Malformed property list" plist))))))

     (define (raise-foreign-error . plist)
       (raise (apply make-foreign-error plist)))

     (define (foreign-error-ref ferr property . args)
       (let* ((table (%foreign-error-table ferr))
              (value (hash-table-ref/default table property #f)))
         (if (procedure? value) (apply value args) value)))))

----------------

John's high level localization proposal:

We, or at least I, have been thinking in terms of localizing the
message and potentially other properties.  What if we did localize the
whole status object?

(foreign-status-localize foreign-status language-tag)

returns a new foreign-status object, this one with all localizable
properties localized to according to the language-tag (a string).

That way we can (for the moment, at least) forget about lambda
properties and all those complexities.  The procedure looks at the
status-type (new suggested name for error-set), calls on whatever
localization facilities it has, substitutes the local messages for the
universal ones, and off we go.  Of course if you don't *want*
localized messages, you don't have to call this.  And if your
implementation knows nothing of that type, it just returns its
argument.

(register-foreign-status-type status-type proc)

This registers a localizer procedure for the status-type.

----------------

