LC 2 changes
Wolfgang Corcoran-Mathe
(10 Jul 2020 02:40 UTC)
|
Re: LC 2 changes
(no sender)
(10 Jul 2020 06:04 UTC)
|
Re: LC 2 changes
John Cowan
(10 Jul 2020 20:21 UTC)
|
Re: LC 2 changes (no sender) (10 Jul 2020 20:50 UTC)
|
Re: LC 2 changes
John Cowan
(10 Jul 2020 22:33 UTC)
|
Re: LC 2 changes
Wolfgang Corcoran-Mathe
(10 Jul 2020 23:55 UTC)
|
Re: LC 2 changes
John Cowan
(11 Jul 2020 15:13 UTC)
|
Re: LC 2 changes
(no sender)
(11 Jul 2020 19:09 UTC)
|
Re: LC 2 changes Marc Nieper-WiÃkirchen 10 Jul 2020 20:50 UTC
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