I don't see that there's much difference between the protocol conversions lisp->, values->, lisp-values->, and exception->; they should have systematic names.  I prefer them to be procedures rather than a mixture of procedures and syntax, and I think the extended -> convention is perfectly fine once it is explained.  The particular choices of name components I admit are not very good, and if anyone has different ones, I'll absolutely consider them.

The problem with using guard to implement exception->either or anything like it is that it breaks if something inside the thunk/body does a raise-continuable which is to be intercepted by a handler that catches it and returns values to the caller.  A guard expression's default action in the absence of an else-clause will change that to a raise instead, which means there is no way back (an attempt to return from the handler will just raise another exception).  Using an else-clause is even worse, because then the call/cc makes it outright impossible to return.

On Tue, Jun 9, 2020 at 3:39 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
Am Di., 9. Juni 2020 um 19:53 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> I'm going to stick with the -> convention for SRFI 189 at least, with explanatory text like this:

Are you solely talking about the conversion procedures here or also
about what you have tentatively (?) named `exception->either'? I hope
instead that you like `either-guard' as syntax.