LIBUCL
fructure
Our great sponsors
LIBUCL | fructure | |
---|---|---|
5 | 8 | |
1,594 | 443 | |
- | - | |
7.9 | 3.7 | |
4 days ago | 3 months ago | |
C | Racket | |
BSD 2-clause "Simplified" License | 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.
LIBUCL
-
That's a Lot of YAML
Have you seen ucl? https://github.com/vstakhov/libucl
It seems very similar.
-
Structured configuration in Go
Structured configuration is the type of configuration language I wanted for Djinn, whereby parameters could be grouped together into blocks, and nested within each other. Hence, the structure. The language I came up with was heavily influenced by HCL, and libucl and has support for duration and size literal values. Below is what the language looks like,
- Libucl: Universal configuration language parser library
- An Intuition for Lisp Syntax
-
The YAML file of Prometheus Operator has over 13k lines, one of the longest YAML files on GitHub ever
Here you go: https://github.com/vstakhov/libucl
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
What are some alternatives?
yaml-cpp - A YAML parser and emitter in C++
vlime - A Common Lisp dev environment for Vim (and Neovim)
frozen - JSON parser and generator for C/C++ with scanf/printf like interface. Targeting embedded systems.
cmu-infix - Updated infix.cl of the CMU AI repository, originally written by Mark Kantrowitz
YAJL - A fast streaming JSON parsing library in C.
coherence - Oracle Coherence Community Edition
RapidJSON - A fast JSON parser/generator for C++ with both SAX/DOM style API
slime - The Superior Lisp Interaction Mode for Emacs
JsonCpp - A C++ library for interacting with JSON.
slimv - Official mirror of Slimv versions released on vim.org
Boost.PropertyTree - Boost.org property_tree module
racket-binfmt - A binary format parser generator DSL with support for limited context-sensitivity.