As originally written, `guard` invokes `raise-continuable` when none of the guard clauses is satisfied (which implies that there is no `else` clause). That is the Right Thing, because it means that whether or not the original raising procedure was `
raise` or `raise-continuable`, the `guard`-expression will return control to it.

Unfortunately, erratum #17 changed the prose and the sample definition to use `raise` instead. The change to the sample definition was correctly undone, but the change to the prose was not. I have just corrected https://bitbucket.org/cowan/r7rs/src/
errata/spec/r7rs.pdf to make the prose say "raise-continuable'

The list of R7RS errata already said that #17 had been undone, so no change needed there. However, any implementers that copied the definition of `guard` should check to make sure their definition of `guard` invokes raise-continuably rather than raise.
Chibi is definitely wrong, and I'm filing a ticket for it.

John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org Micropayment advocates mistakenly believe that efficient allocation of resources is the purpose of markets. Efficiency is a byproduct of market systems, not their goal. The reasons markets work are not because users
have embraced efficiency but because markets are the best place to allow
users to maximize their preferences, and very often their preferences are
not for conservation of cheap resources. --Clay Shirky

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)