fructure VS racket-gui-easy

Even the racket teachpack libraries designed for education are very capable; I was able to make this structured editor with only using teachpack content without external deps: https://github.com/disconcision/fructure

Right, it's fine, and is a pretty basic macro. Doubly linked lists are pretty basic data structures too, even the Rust versions once you figure it out. I like your sibling comment making it look like the CL version. I still want to know in more detail though why you think that doing things this way instead of the CL way is less likely to be "fragile and break down" for the complicated stuff, it would help to have a specific complicated example to showcase. Perhaps the linked https://github.com/disconcision/fructure in another comment would be a good study? The author there claimed they might not have been able to manage with defmacro, maybe someone familiar with both could articulate the challenges in detail. Is it just an issue of some things benefit a lot from pattern matching, and if so, does using CL's Trivia system mitigate that at all (in the same way that using gensym+packages+Lisp-2ness can mitigate hygiene issues)?

see also: fructure

Looks like you're already in Emacs. I strongly recommend racket-mode as mentioned in another thread.

With regard to prototyping GUI's I'd suggest taking a look at https://github.com/mfelleisen/7GUI. https://github.com/Bogdanp/racket-gui-easy could also be a good place to start.

With regard to Racket more generally, I'm probably not the best person to ask since I had a very high friction start where I just banged my head against the wall until things made sense.

I took a similar approach in my Racket library, gui-easy[1,2]. Though I opted to not defer any computations, any observable (similar to a signal from the post) update propagates to observers immediately, and there's no incrementality -- observables are just boxes whose changes you can subscribe to. Regarding the disposal problem, I used weak references and regarding the where to take observables and where to take concrete values as input question, I decided that any place an observable can go in, a concrete value can as well and it's been a convenient choice so far. For fun, here's an example[3] that builds the todo UI from the post.

[1]: https://docs.racket-lang.org/gui-easy/index.html

For native apps, I would devote coding resources to the Guile-GI project which generates Guile bindings to the cross-platform Gtk C library by way of the Gnome Object Introspection and Reflection library. I would also port the Racket gui-easy library over to Guile-GI so declarative GUIs could be written.

There is also gui-easy a declarative gui framework: https://docs.racket-lang.org/gui-easy/index.html

It’s not the only version either

See https://github.com/Bogdanp/racket-gui-easy/tree/master/examp...

  },