xl
kdl
xl | kdl | |
---|---|---|
6 | 14 | |
266 | 1,043 | |
- | 3.1% | |
10.0 | 5.6 | |
over 1 year ago | 26 days ago | |
C++ | ||
GNU General Public License v3.0 only | GNU General Public License v3.0 or later |
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.
xl
-
XL: An Extensible Programming Language
From what I can read the author got really unlucky with some kind of radical API changes. Maybe at that time the LLVM team was a bit less serious with deprecations ?
I use LLVM since v9, nowadays I'm stuck on v15 (that's not because of LLVM btw).
Between the two versions there's been a radical change too, i.e "opaque pointers", but the transition was rather smooth as we were provided, for a long time, the two versions of the functions affected by the change. Maybe the LLVM team got more serious since the author experienced the said difficulties ?
Other thing I note is that the author uses the CPP API. I use the C one which exposes only a high-level subset of the CPP one. This encourages a saner use of LLVM, a more concrete separation between the front-end and the mid-end, although sometimes there are limitations.
A simple example of what encourages the C API, especially since opaque ptrs are added, is not to rely on LLVM to retrieve the IR type of an IR value. That should always be done using the AST, eg with an `.ir` field in your nodes.
Another one I remark, after a brief overview of LLVM-CRAP, is that the author had to change the internal data structure used, depending on the LLVM version [0]. Using the C API that would never had happened. The C API essentially allows to create block refs, instructions refs, value refs, type refs, contexts. Then you choose the containers you want to use to hold them. No need to switch to another stdcpp one, even if internally LLVM does so.
[0]: https://github.com/c3d/xl/blob/master/src/llvm-crap.cpp#L265
- Ask HN: Cool Useful GitHub Repos?
kdl
-
XL: An Extensible Programming Language
IMO, there’s a wide unexplored design space between the minimalism of Lisp and richness of other languages. A programming language inspired by something like KDL (https://github.com/kdl-org/kdl) has the potential to be in a very sweet spot between the two. "Everything is a node" instead of "everything is a list" is only slightly more complicated, but also vastly more readable that a soup of parenthesis.
- Things you didn't know you could fuzz - FuzzingWeekly CW17
- Things you didn’t know you could fuzz: - FuzzingWeekly CW17
-
SDLang – Simple Declarative Language
KDL is a variant of SDLang that’s worth checking out.
https://github.com/kdl-org/kdl
- KDL
-
Parsing JSON is a Minefield 💣 (2018)
Either way I've got high hopes for KDL becoming the new gold standard for clean, flexible data formats that are editable by hand.
-
The KDL Document Language
I'd love to understand why all the advertised implementations have permissive licenses except for the Rust implementation, which is released under the Parity Public License 7.0.0 [1]? This seems to be as restrictive as the GPL, no?
In my mind, copyleft licenses applied to infrastructural projects like kdl-rs prematurely limits their adoption and promotes the development of alternatives with more permissive licensing, since the spec is released under a Creative Commons license [2].
[1]: https://github.com/kdl-org/kdl-rs/blob/87f836134c1d901ff5ce6...
[2]: https://github.com/kdl-org/kdl/blob/785abebfc507ff6b7bdeac07...
-
The KDL Document Language, an alternative to YAML/JSON/XML
p.s. if anyone is interested in helping or just wants the info, this is the tracking issue for implementations supporting 1.0 (the actual thing that just got released): https://github.com/kdl-org/kdl/issues/144
-
ParserObjects Parser Combinator Library for .NET
Oh nice. It will be a nice library to use to parse KDL (https://github.com/kdl-org/kdl)
-
The YAML file of Prometheus Operator has over 13k lines, one of the longest YAML files on GitHub ever
It's still in its infancy but I'm keeping an eye on kdl
What are some alternatives?
Modern_GUI_PyDracula_PySide6_or_PyQt6
ron - Rusty Object Notation
Modern_GUI_PyDracula_
json5 - JSON5 — JSON for Humans
db48x - RPL runtime for the DM42 calculator, in the spirit of HP48/49/50
prometheus-operator - Prometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes
ghc - Mirror of the Glasgow Haskell Compiler. Please submit issues and patches to GHC's Gitlab instance (https://gitlab.haskell.org/ghc/ghc). First time contributors are encouraged to get started with the newcomers info (https://gitlab.haskell.org/ghc/ghc/wikis/contributing).
config - configuration library for JVM languages using HOCON files
jsonjsc - A Python JSONDecoder library for parsing out Javascript comments in JSON files.
dhall-lang - Maintainable configuration files
Slim - Slim is a template language whose goal is to reduce the syntax to the essential parts without becoming cryptic.
LIBUCL - Universal configuration library parser