Am Mo., 21. März 2022 um 16:12 Uhr schrieb Dr. Arne Babenhauserheide
<xxxxxx@web.de>:
>
>
> Linas Vepstas <xxxxxx@gmail.com> writes:
>
> > I'd like scheme to be as-fast-as-possible, as what else is it offering the world? it's not going to be python or java or rust. It may as well be tight.
>
> One thing that impressed me about Scheme is that, while not being totally
> about performance, it avoided features that forced using hard to
> optimize approaches.
>
> That’s where I see the role of the standard: leave the implementations
> to actually produce the high performance code, but take care to make
> their job easy.
>
> Making a high-performance Scheme should not require building a huge V8
> or SpiderMonkey or Javascript Core system with their massive memory
> consumption and bulging complexity. Those are the consequence of
> language-design-by-accident. The same goes for Java and the JVM. Yes, it
> is awesome what performance they got, but it should not be that hard.

I think you make a very good point here.

> Finding the right limitations for a language to make it easy to optimize
> without placing the burden on the programmers is hard; but it’s one of
> the things that make Scheme special to me.
>
> I loved it that the discussion about ER and syntax-case was decided on
> the basis of “we can only have one, because if we implement one, the
> other provably¹ requires more than O(N) for expansion”.
>
> ¹: I did not see the proof, though — maybe I should have dug deeper.

Our proof is currently not a mathematical proof but proof by lack of
falsification. :)

A formal argument would be based on that syntax-case requires the
identifiers in the output of a macro transformer to be marked and ER
requires fully unwrapped syntax objects as the input to a macro
transformer.

There are, of course, loopholes if you overload car and cdr so that
car and cdr transparently unwrap syntax objects. But then you probably
slow down all list operations because car and cdr would need to
dispatch on the type of their arguments.