>> Among other things, Racket's current envisioned path of ditching
>> S-expressions for an infix syntax suggests, absent a fork that long
>> term collaboration was never in the cards.  But I don't know enough
>> about it, I never found it or its predecessors interesting.
>
> If I look at what they are doing, I can only take off my head to them.
> While I may or not may like everything they put into Racket, they do
> invent new things and develop the language further (on a certain scale
> much more than we do here as we do mostly trivial things). Whether we
> like it or not, Racket has probably a much higher chance to survive in
> the long term than R7RS (large). Anyway, I can't speak for the Racket
> people, but reading old mailing lists from the time when Scheme was
> forked into R6RS and R7RS, it doesn't sound that they would have
> abandoned RnRS if R7RS didn't break with its predecessor.

This may be the seminal thread on infix Racket:
https://groups.google.com/forum/m/#!msg/racket-users/HiC7z3A5O-k/XPR2wbSJCQAJ

Here's a wish list for the next version of Racket:
https://github.com/racket/rhombus-brainstorming

I also have a ton of respect for both the technical and the
community-building abilities of the Racket team. Matthew Flatt in
particular is extremely impressive for the scale and success of his
efforts. It's hard to believe one person can get so much done.

Nevertheless, reading those wish lists and reflecting on them, I don't
believe in the vision. It's not about simplifying things and moving the
fundamentals of programming on to the next stage. Tracing back the
history of Lisp, there used to be an air of bootstrapping the future.
Invent powerful tools so that a small group of people can make the next
chapter of computing a reality.

The Cornell Program Synthesizer was published in 1981
(http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.216.9200&rep=rep1&type=pdf).
Here's the abstract:

"Programs are not text; they are hierarchical compositions of
computational structures and should be edited, executed, and debugged in
an environment that consistently acknowledges and reinforces this
viewpoint. The Cornell Program Synthesizer demands a structural
perspective at all stages of program development. Its separate features
are unified by a common foundation: a grammar for the programming
language. Its full-screen derivation-tree editor and syntax-directed
diagnostic interpreter combine to make the Synthesizer a powerful and
responsive interactive programming tool."

Given this and many other prototypes over the decades, why is something
like an infix syntax even on a research agenda in 2020? We should be
using GUIs to edit a structural representation of code. Since we are
Lispers and we like macros, we should have visual macros that display
bits of code as GUI widgets. If people can configure their GUI to show
whatever kind of syntax they like, and style their macros, why is it
even interesting to tinker with the underlying text syntax? There's no
reason to move beyond Lisp's simple and effective S-expressions because
text syntax of any kind has been obsolete for decades. S-expressions are
a fine on-disk representation and we can keep them. We just need to
finally add a real user interface on top.

If anyone lurking on these lists is enthusiastic to really modernize
Scheme, let's just hack up a prototype and get structural editing and
visual macros started. Wouldn't it be cool if Scheme was the first
language to have them? We are a small community but we can innovate.
That has always been the Lisp spirit.