> Don't get me wrong, but I thing it would have been appropriate to
 > withdraw this srfi, just as srfi 245 was withdrawn, until the issues
 > raised in the discussion of the issues are fully resolved.
Good point. Could you please be a bit more specific -- I thought
that the changes made to the SRFI mid-flight were made to address
the issues raised in the discussion. There is, of course, always an
issue of weak rationale (to quote: just use nested 'let's), but, in my
opinion, the fact that there were two proposals on the same matter
proves that this is something people keep thinking about.

On Thursday, April 25, 2024 9:37:09 PM (-04:00), Lockywolf Laptop wrote:

 >
 > "Arthur A. Gleckler" <xxxxxx@speechcode.com> writes:
 >
 > > Sergei Egorov, author of SRFI 251: Mixing groups of definitions with
expressions within bodies, has asked me
 > > to announce last call for this SRFI. He believes that it is ready for
finalization, but would like to give
 > > reviewers one last chance to submit corrections and feedback before we
finalize it.
 > >
 > > In particular, I appeal to anyone reading this to try the sample
implementation, run the tests, and send
 > > feedback about your results.
 > >
 > > Note that SRFI 245, an earlier proposal in a similar vein but with
important differences, has been withdrawn.
 > > Regardless of the status of each SRFI, both will remain public so that
Scheme implementers can consider the
 > > ideas in both.
 > >
 > > If you're interested in this SRFI, please give your feedback via the
SRFI 251 mailing list before 2024-05-01.
 > > After that, assuming that no major revisions are required, we will
declare it final. It is important that we
 > > get your feedback before 2024-05-01. If that deadline is too soon for
you, but you would like to contribute,
 > > please let me know so that I can extend the last-call period.
 > >
 > > Regards,
 > >
 > > SRFI Editor
 >
 > Don't get me wrong, but I thing it would have been appropriate to
 > withdraw this srfi, just as srfi 245 was withdrawn, until the issues
 > raised in the discussion of the issues are fully resolved.
 >
 > While it is certainly nice to add some imperative code at the beginning
 > of a procedure, in order to verify input, and in order to debug the
 > code, the (seemingly) main motivation behind this SRFI "look UP the
 > code" is not exactly widely used nowadays, after "define scan-out" has
 > been invented. If anything, the formulation should be "look UP the
 > translation PHASE" rather than "UP the code".
 >
 > If strictly required, any sequencing of operations can be enforced by
 > the usage of nested lets.
 >
 > That is just an opinion, of course.
 >

--
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com