Am Fr., 10. Juli 2020 um 22:21 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> I still hope that it comes back to the syntax section by my reasoning
>> in the other thread because it is more easily optimizable and much
>> more convenient to use this way.
>
>
> A procedure it is and into the "Protocol Conversion" section it has gone, par fatwa du petit mufti.  (Etymological note: The two Arabic words are closely related, sharing the same consonantal root F-T-Y/W; a fatwa is an opinion, and a mufti is one who formally issues opinions.)

It is unfortunate that this isn't being resolved by some rationale
argument. You gave an argument about iterating over a list of thunks
but that has been defeated. Now we have to put lambdas into most uses
of 'exception-:(->either' for no reason (that has been presented). The
'guard' form, which is somewhat the convenient version of
'with-exception-handler' and which is semantically the closest to
'exception-:(->either' is also syntax.

>> > (3) How strictly should we read "A claw is either an identifier
>> > bound by an earlier claw..."?  Is it an error, for example, if an
>> > identifier appears which was bound outside of the -let* form, e.g.

>> I think It is morally an error in SRFI 2 to allow only bound
>> variables. We don't have to repeat it.
>
>
> I think we do; too confusing otherwise.

Now that I have read SRFI 2 again, it doesn't say that the variable
has to be bound in the and-let* form. It just says that the variable
has to be bound, which is a perfectly valid prerequisite, and
referencing an unbound variable is an error anyway.

So it is actually the current wording in SRFI 189, which is in
contradiction to SRFI 2. Please excuse my sloppy reading of SRFI 2
earlier.

Marc