fructure
racket-binfmt
fructure | racket-binfmt | |
---|---|---|
8 | 1 | |
442 | 11 | |
- | - | |
3.7 | 4.9 | |
3 months ago | 4 months ago | |
Racket | Racket | |
Apache License 2.0 | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
fructure
-
Racket: The Lisp for the Modern Day
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
-
Common Lisp vs Racket
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)?
- Fructure: A structured interaction engine in Racket
-
graph-based UI for Lisp/Scheme
see also: fructure
- Why text only.
- An Intuition for Lisp Syntax
racket-binfmt
-
Racket: The Lisp for the Modern Day
Racket internalizes Extra-linguistic mechanisms https://felleisen.org/matthias/manifesto/sec_intern.html
Also the fact that various DSLs can inter-op with each other directly, so that you can use something like a binary parser description, as if it was just another Racket library. For example this description of the format https://github.com/Bogdanp/racket-binfmt/blob/master/binfmt-..., is directly included in another file as a regular library https://github.com/Bogdanp/racket-binfmt/blob/master/binfmt-...
I agree that startup time is not a winning aspect of Racket. My naive understanding is because Racket is not a direct bytecode interpreter like CPython, but actually has to run a compile step to native code, and doing that for programs + their required libraries necessarily takes at least a couple of hundred milliseconds even before anything can start running, while CPython can pretty much start executing from the get go.
What are some alternatives?
LIBUCL - Universal configuration library parser
frog - Frog is a static blog generator implemented in Racket, targeting Bootstrap and able to use Pygments.
slimv - Official mirror of Slimv versions released on vim.org
Energy-Languages - The complete set of tools for energy consumption analysis of programming languages, using Computer Language Benchmark Game
vlime - A Common Lisp dev environment for Vim (and Neovim)
7GUI - the 7 gui project
cmu-infix - Updated infix.cl of the CMU AI repository, originally written by Mark Kantrowitz
racket-gui-easy - Declarative GUIs in Racket.
coherence - Oracle Coherence Community Edition
awesome-lisp-companies - Awesome Lisp Companies
slime - The Superior Lisp Interaction Mode for Emacs
pollen - book-publishing system [mirror of main repo at https://git.matthewbutterick.com/mbutterick/pollen]