Am Fr., 23. Juli 2021 um 14:39 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> "Being of the exactly right exception type" is just another predicate. :)

Agreed - and should be.

> Anyway, it is part of the API of the standard R6RS library that
> inspection is possible with R6RS condition objects. Likewise, R7RS has
> some inspection, e.g. through `error-object-message'.

The problem is R6RS dictates that standard procedures raise particular
condition types which are defined as concrete types arranged in a
particular hierarchy of concrete types. Inspection can then be used to
check for those types and their parents, without using any predicates.

R6RS dictates that the procedures exported by its "rnrs" libraries raise the particular condition types you are talking about.  This is just analogous to, say, SRFI 170, which dictates that its procedures raise a certain kind of condition object that can be inspected and for which `posix-error?' returns true.

If we can relax the R6RS requirement that the conditions need to have
the given concrete types, and we only promise that the _predicates_ with
the standard names conform to the R6RS hierarchy, it's all good.

I don't understand why this would be sensible (or whether it would change anything). Any Scheme object is defined through what you can do with it (cf. duck-typing). When I have an object for which `posix-error?' returns true, I know that I can do a number of things with it, like invoking `posix-error-name' on it. Similarly, if I have an object for which `who-condition?' returns true, it is guaranteed that it will behave in certain ways (like that `record?' applied to it returns true and that I can invoke `condition-who' on it).

Some other library may export the name `who-condition?' as well but with different bindings and with different semantic implications.

> I mean, every
> library (or system of libraries like R6RS) is free choose which kind of
> objects it uses to represent exception conditions and what predicates
> and accessors it exports. All that is important is that the RnRS do not
> dictate a particular type of object as an argument to `raise'.

Is it really the case that R6RS doesn't guarantee standard procedures to
raise conditions of given concrete types? I had the opposite impression.

It does guarantee this when "standard procedure" means a procedure exported by some `(rnrs ... (6))' library.  It says nothing about procedures in `(scheme base)' or `(srfi :666)'.

If R6RS doesn't require the standard condition types to be inspectable,
that would work as well.

For your own library system (or for the R7RS large libraries or for whatever SRFI), you can of course copy the R6RS predicate hierarchy but without any further guarantees. Whether this would be helpful is rather questionable. (*)

Marc

--

(*) The following is an example where it makes sense to know that I can do more with my duck than just knowing that it is a duck:

(define frobnicator

  (lambda (foo bar baz)

    (guard (c

            [(assertion-violation? c)

             (raise (condition (make-who-condition 'frobnicator) c))])

      (bla foo)

      (blubb bar baz))))

Here, `frobnicator' doesn't check its arguments because it knows that invoking `bla' or `blubb' will raise an assertion violation in case the arguments are of the wrong type. As the calls to `bla' and `blubb' should be implementation details, `frobnicator' adds the correct external `who' component to every raised assertion violation.