Am Mi., 16. Juni 2021 um 01:08 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

On Tue, Jun 15, 2021 at 10:33 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

Okay, it was the compilers to machine code that I had in mind and that try to achieve code efficiency so that Scheme code has chances to rival C.

But we must at least consider all Scheme systems.

Sure. Different Scheme systems need different measures to run code efficiently.
 
If you want to beat a C for loop with higher-order procedures in Scheme,

A worthy activity, but definitely not the only criterion that matters; indeed to some Schemers it is a very unimportant criterion.

Sure again. But this discussion has been about efficiency.
 
I believe that closure allocation needn't be expensive nor that it should in a language like Scheme (because, otherwise, the implementation fails to handle idiomatic code efficiently).

It isn't allocation that's expensive, it's the resulting GC pressure and whether you can optimize it away.  Fast Scheme compilers like Chez attempt to avoid allocation of closures rather than making it fast: is that what you have in mind?

It very much depends on the Scheme implementation what you can do and what you have to do. But, yes, when I wrote "closure allocation" I was sloppy. I should have written that it is more important to make, say, creation of procedure values fast in Scheme than, say, variable assignment.
 
Closure allocation shouldn't be much more expensive than a cons, and compilers like Chicken seem to prove this. In Chicken, all the code is CPS transformed, meaning that every continuation becomes a closure (meaning that a closure is involved in every non-tail call), and Chicken code can be fast.

Meaning that everyone pays an amortized price for closures (and continuations).   The other view is the C++ (and Chez) one, that users should only pay for features they actually use.

Chicken was just an example where each computation step, at least principally, involves creating a closure and proof that it can be implemented efficiently. Creating procedure values is even faster in Chez than in Chicken.
 
I understand. A similar question is: Should we design a library or a core library function (like make-coroutine-generator in SRFI 158) so that relies on an efficient implementation of call/cc? I would say, yes, because a Scheme that cannot handle call/cc efficiently shouldn't dictate an API for the rest of the Scheme world.

But when the "can't handle call/cc efficiently" is in fact most of the Scheme world, as I believe it is, then what?  Not wanting the tail to wag the dog is fine, but which is the dog and which is the tail?

Wasn't one complaint about R6RS that only a few implementations would be able to adopt? So R7RS was split into two parts, the small language for simpler implementations that had targeted R5RS before, and the large language as some kind of R6RS++? If we still make sure that R7RS-large runs on the "50+ toy implementations of Scheme", we won't get far and won't get a convincing result.

If it is the view that Schemes regularly handle call/cc and the creation of closures inefficiently, then we can just as well remove call/cc from the standard and try to avoid some typical functional programming patterns. But then, there's no point in calling it Scheme anymore. And any distinction to the myriads of other programming languages would be lost.