Follow

Well we talked about it briefly on today's Rhombus call, and the possibility of a non-parenthetical tree-based syntax is on the menu for next meeting, and I made a Wraith PR as well: github.com/racket/rhombus-prot

Thanks to the Racket folks for tolerating me jumping into the meeting at last minute and raising my concerns, and expressing support for conversation on this in the next meeting.

· · Web · 1 · 3 · 9

@cwebber Thank you also for mentioning Wisp there. I’m trying to hold off from writing more, because I’m not really deep enough in racket for that. I hope the input I could provide will be useful.

If there’s something I can help with, feel free to ping me!

@ArneBab I still think the choices in Wraith are more in tune with what the Racket community wants. I myself would be perfectly happy with Wisp. But there are a couple of things, like the way for syntax looks so nice in Wraith, that mesh well with Racket-land.

@cwebber Yes, Wraith does match pretty well what’s beneficial for a language that moves into the core of Racket.

But for Wisp I have examples of real code I write to solve real problems, so people don’t just see how code looks on the happy path — and it’s readable. That’s why I hope that it can show that s-expressions are not the problem.

Also I wrote it, and I still like it 8 years later (8 years already …), so I prefer showing it :-)

@cwebber I’m so happy to hear¹ that :-)

¹: well, read :-)

Wisp has become my main programming language for anything except of work or lager existing projects — which is in part possible because it is just Scheme: There is nothing to change to take advantage of advances in Scheme.

@ArneBab The main thing Wisp and Wraith both are missing is tooling.

But what if Wisp/Wraith could learn from Fructure? youtube.com/watch?v=CnbVCNIh1N

What if Wisp/Wraith did something akin to rainbow-delimeters-mode, but instead lightly highlighted the background colors, drawing "shapes" around the boundaries of expressions?

@cwebber @ArneBab I had an idea of a "closer-to-text version of Scratch" that would basically present a text editor, but with colored boxes around expressions. I guess great minds think alike!

My idea also involved a palette of forms (again, a Scratch concept). It's meant to help transitioning from block-based to textual programming.

But then again, things with working implementations beat paper ideas anytime! :blobcatcoffee:

Sign in to participate in the conversation
Octodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!