Am Mo., 4. Dez. 2023 um 13:58 Uhr schrieb Sergei Egorov <e...@acm.org>:
> > On Dec 4, 2023, at 8:21 AM, Marc Nieper-Wißkirchen <marc.nie...@gmail.com> > wrote: > > > Am Mo., 4. Dez. 2023 um 12:11 Uhr schrieb Sergei Egorov <e...@acm.org>: > >> >> I would like to repeat the argument that seems to be lost in the >> discussion. After giving it some thought, now I can see that the two SRFIs >> are not entirely incompatible. >> >> What if we explicitly mark situations where there is an identifier that >> would refer to an outside scope in SRFI-251 semantics while referring to >> "over-the-run-of-commands" definition according to SRFI-245 semantics, and >> only those situations, as "it is an error"? Would it still leave enough >> useful programs "in the clear"? If this is so, both SRFIs become different >> implementation strategies for the same common idea; all current >> implementations of both STFIs would stil be compliant, stepping into "is an >> error" territory in different ways, but giving the compliant bodies the >> same meaning. >> > > The problem with this approach is that - unless it becomes mandatory to > raise an exception when in the "it is an error situation" - Schemes and > programs will start to diverge. > > > True if you are firmly in the "all errors must raise exceptions" camp; I > am not, both as user and an implementor. Schemes were diverging from the > very start, and the freedom of handling "it is an error" situations allowed > them to scale easily in both directions. I think that nothing seriosly bad > came out of this freedom. But that's a philosophical issue, too complicated > to discuss here. > I am not against experimentation and individual Schemes extending the standard; quite the contrary. But I firmly believe that it should happen in a controlled sense so that no compatibility problems will show up later, at least in times of R6RS and R7RS, where we have a library system. For if the Scheme fantastic-scheme extends the capability of `lambda', it should not extend `lambda' as exported by `(scheme base)' or `(rnrs base (6))' but the `lambda' as exported by `(fantastic-scheme)'. I think there is some truth to saying that progress in the Scheme world has been so slow because of the anarchic freedom that has been given to implementers. There's still a need to insert an occasional command in the middle of a run >> of mutually recursive definitions, and it can be addressed by introducing a >> *define! >> *form (any other name would do), such that (define! <command>) is a >> definition, so it does not interrupt the "run" of definitions. It can be >> just a macro expanding into R7RS (define-values () (begin <command> >> (values)) or something implementation-dependent with the same semantics. >> In fact, just this form alone can solve all the problems mentioned in >> rationale, albeit a little more clumsily. >> > > This approach has the advantage that no change to any expander is > necessary and that it already works in R5RS, R6RS and R7RS-small. > > The name "define!" should be bike-shedded, of course. :) I would also > make it a form taking zero, one or more commands. > > A similar approach is to extend define-values: > > (define-values <formals> > <definition> ... > <command> ... > <expression>) > > will expand into > > (define-values <formals> > (let () <definition> ... <command> ... <expression>)) > > This will already cover a lot of use cases, namely to allow long > calculations for local variables appearing before the point of definition. > > For the other use cases, > > (define-values #f > ...) > > will expand into > > (define-values <tmp> > ... > #f) > > One restriction of RnRS would still apply, namely that every form is > either an expression or a definition. One cannot write a general > `check-argument' macro that expands into the correct form in each context; > but this is possibly a good thing. > > Marc > > > I agree on all counts ) > Perhaps we can stick with it and see what happens? > > >
