Where to start?

[mnieper]

This can be a starting point: http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-8.html#node_sec_7.3

Thanks to both inheritance and compound conditions, the system is very flexible so should be adaptable/extendable easily.

[lassik]

@johnwcowan Do you concur?

[johnwcowan]

Perhaps unsurprisingly, I don't concur at all. By the way, the hierarchy (Fig. 7.1) is much more legible in the PDF version on p. 28.

1. "Is an error" is intended to provide extension points to the interoperable definitions of R[57]RS as opposed to the portable definitions of R6RS as well as to provide flexibility in error handling.

2. One of the specific pain points that people had in converting, or rather not converting, their Schemes to R6RS was precisely conditions.

3. The standard condition types of R6RS form a hierarchy rather than a heterarchy, and existing implementation hierarchies don't find it easy to adopt.

4. The line between single inheritance and compound conditions is arbitrary. CL does not need compound conditions, because its class and condition types already provide multiple inheritance.

5. Multiple inheritance is very complex, and nobody has gotten it right to date.

Therefore I favor using compounds only. I'm not entirely happy with CompoundObjects; it needs some improvements. But I think it is along the right lines.

[mnieper]

Am Di., 20. Okt. 2020 um 16:42 Uhr schrieb John Cowan notifications@github.com:

Perhaps unsurprisingly, I don't concur at all. By the way, the hierarchy (Fig. 7.1) is much more legible in the PDF version on p. 28.

"Is an error" is intended to provide extension points to the interoperable definitions of R[57]RS as opposed to the portable definitions of R6RS as well as to provide flexibility in error handling.

I think the point is not to force a system to signal an error when, say, (car #f) is evaluated, but to standardize what exception should be raised in case the implementation wants to signal an error.

One of the specific pain points that people had in converting, or rather not converting, their Schemes to R6RS was precisely conditions.

Can this claim be backed up?

The standard condition types of R6RS form a hierarchy rather than a heterarchy, and existing implementation hierarchies don't find it easy to adopt.

Thanks to compound objects, it is a very flexible hierarchy. Which existing hierarchies cannot be adopted at all?

The line between single inheritance and compound conditions is arbitrary. CL does not need compound conditions, because its class and condition types already provide multiple inheritance.

As we do not have multiple inheritance, we do not have to talk about the CL system. In what sense is the line arbitrary? The shallow single inheritance diagram just ensures that some compound elements are implicit. E.g., every &violation is, abstractly, bundled with a &serious condition. That can be helpful.

Multiple inheritance is very complex, and nobody has gotten it right to date.

Therefore I favor using compounds only. I'm not entirely happy with CompoundObjects; it needs some improvements. But I think it is along the right lines.

Do not reinvent the wheel unless necessary.* Or, said differently, do not create barriers for R6RS systems to adopt R7RS-large in the long run.

• Unless it can be proven (and not only claimed) that the new system can be adopted by implementations while the old system can't.

[mnieper]

PS The thing of the R6RS exception system, which undoubtfully can become hard to implement on a random Scheme system with a native exception system, is the runtime part consisting of with-exception-handler, raise, and raise-continuable.

But this hasn't changed from R6RS to R7RS, so all systems that support R7RS already support the hard part.

[lassik]

"Is an error" is intended to provide extension points to the interoperable definitions of R[57]RS as opposed to the portable definitions of R6RS as well as to provide flexibility in error handling.

I think the point is not to force a system to signal an error when, say, (car #f) is evaluated, but to standardize what exception should be raised in case the implementation wants to signal an error.

Even better, since exceptions are distinguished by calling a predicate procedure in R7RS, we could turn each R6RS condition type into a predicate for R7RS.

That would also solve the hierarchy-vs-heterarchy problem, since predicates don't care which it is.

[mnieper]

Each R6RS condition type defines a predicate, so mapping in one direction is obvious.

On the other hand, predicates alone do not allow to create conditions of that type at runtime, nor do they allow to access the payload of condition objects.

Am Mi., 27. Jan. 2021 um 12:44 Uhr schrieb Lassi Kortela < notifications@github.com>:

"Is an error" is intended to provide extension points to the interoperable definitions of R[57]RS as opposed to the portable definitions of R6RS as well as to provide flexibility in error handling.

I think the point is not to force a system to signal an error when, say, (car #f) is evaluated, but to standardize what exception should be raised in case the implementation wants to signal an error.

Even better, since exceptions are distinguished by calling a predicate procedure in R7RS, we could turn each R6RS condition type into a predicate for R7RS.

That would also solve the hierarchy-vs-heterarchy problem, since predicates don't care which it is.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pre-srfi/r7rs-condition-hierarchy/issues/1#issuecomment-768230088, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHDTQ4U34TP62BNWRMHDXLS374AFANCNFSM4SX6LYMA .