rakudo
instaparse
rakudo | instaparse | |
---|---|---|
55 | 7 | |
1,697 | 2,708 | |
0.1% | - | |
9.9 | 6.0 | |
about 23 hours ago | about 1 month ago | |
Raku | Clojure | |
Artistic License 2.0 | Eclipse Public License 1.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.
rakudo
-
Stability
Fix IO::Path::parent #4795: merged 2022-02-19 Add more IO::Path::parent tests #801: merged 2022-02-19 Change parent to always just remove the last element #4800: merged 2022-02-26 Change .parent behavior to "stupid" resolving #802: merged 2022-02-26
-
Moving printf formats forward
This then became the Formatter class. And since this was a completely new feature, it only became available for use by opting into the 6.e.PREVIEW language version. And then it went largely unnoticed and uncared for the next 1.5 year. As clearly the time wasn't right for it yet.
-
Shaking the RakuAST Tree
The intended audience are those people willing to be early adopters of these exciting new features in the Raku Programming Language. The examples in this blog post will work in the next release of the Rakudo compiler (probably 2023.06), but are now already available in the bleeding edge version.
-
So why is there RakuAST in the first place?
If you really want to look at this, you can find the code in src/Perl6/Grammar.nqp, src/Perl6/Actions.nqp and src/Perl6/World.nqp.
-
A practical example of RakuAST
If you find this very interesting, you probably want to read the RakuAST README. And the actual source code of the RakuAST classes can be found in the same directory. And if you're really feeling adventurous and you have the Rakudo repository checked out, you can have a look at the generated NQP code in gen/moar/ast.nqp.
-
RakuAST for Early Adopters
Yes, it would. But until there was RakuAST, that was virtually impossible to do because there was no proper API for building ASTs. Nor was there an interface to execute those ASTs. And now that there is RakuAST, it is actually possible to do this. And there is actually already an implementation of that idea in the new Formatter class. Although this is definitely not intended as an entry point into grokking RakuAST.
-
What explains this difference in behavior?
I have opened one. https://github.com/rakudo/rakudo/issues/5205.
-
Why isn't sign() defined for Complex numbers?
Will Coleda has made a Pull Request
-
Building Rakudo on JVM backend fails: guarantee(requested_word_size <= chunklevel::MAX_CHUNK_WORD_SIZE) failed: Requested size too large (561049) - max allowed size per allocation is 524288
There's an issue pertaining to this. This is something I'd like to resolve, but I'm unsure on how to better debug this to see if it really is the deserialization of a setting file triggering it. JDK 11 should at least be capable of building Rakudo, but being an experimental backend people don't always align with MoarVM immediately, I can't make any guarantees about tests. You may be disappointed in its performance at the moment.
-
Resources and advice
(NB. While the PL is just a toy (and just a tiny bit of the toy too), the tech is actually industrial strength, used to power the production Raku compiler, which is written in Raku using its grammar construct. Starting easy doesn't mean you can't go far. Quite the opposite in fact -- you can go as far as you want.)
instaparse
-
Chumsky, a Rust parser-combinator library with error recovery
Caveats: I've used nom in anger, chumsky hardly at all, and tree-sitter only for prototyping. I'm using it for parsing a DSL, essentially a small programming language.
The essential difference between nom/chomsky and tree-sitter is that the former are libraries for constructing parsers out of smaller parsers, whereas tree-sitter takes a grammar specification and produces a parser. This may seem small at first, but is a massive difference in practice.
As far as ergonomics go, that's a rather subjective question. On the surface, the parser combinator libraries seem easier to use. They integrate well with the the host language, so you can stay in the same environment. But this comes with a caveat: parser combinators are a functional programming pattern, and Rust is only kind of a functional language, if you treat it juuuuust right. This will make itself known when your program isn't quite right; I've seen type errors that take up an entire terminal window or more. It's also very difficult to decompose a parser into functions. In the best case, you need to write your functions to be generic over type constraints that are subtle and hard to write. (again, if you get this wrong, the errors are overwhelming) I often give up and just copy the code. I have at times believed that some of these types are impossible to write down in a program (and can only exist in the type inferencer), but I don't know if that's actually true.
deep breath
Tree-sitter's user interface is rather different. You write your grammar in a javascript internal dsl, which gets run and produces a json file, and then a code generator reads that and produces C source code (I think the codegen is now written in rust). This is a much more roundabout way of getting to a parser, but it's worth it because: (1) tree-sitter was designed for parsing programming languages while nom very clearly was not, and (2) the parsers it generates are REALLY GOOD. Tree-sitter knows operator precedence, where nom cannot do this natively (there's a PR open for the next version: https://github.com/Geal/nom/pull/1362) Tree-sitter's parsing algorithm (GLR) is tolerant to recursion patterns that will send a parser combinator library off into the weeds, unless it uses special transformations to accommodate them.
It might sound like I'm shitting on nom here, but that's not the goal. It's a fantastic piece of work, and I've gotten a lot of value from it. But it's not for parsing programming languages. Reach for nom when you want to parse a binary file or protocol.
As for chumsky: the fact that it's a parser combinator library in Rust means that it's going to be subject to a lot of the same issues as nom, fundamentally. That's why I'm targeting tree-sitter next.
There's no reason tree-sitter grammars couldn't be written in an internal DSL, perhaps in parser-combinator style (https://github.com/engelberg/instaparse does this). That could smooth over a lot of the rough edges.
-
Langdev in Clojure
Sure, you can use https://github.com/Engelberg/instaparse to create parser for any language you want, or simply create DSL in basic clojure types, like vectors.
-
Formal Specification and Programmatic Parser for Org-mode
Enter org-parser! It is indeed such a thing implemented already! Remember the magical parser I mentioned above? It is already implemented here Engelberg/instaparse too (in a Lisp)! org-parser is built on top of it by providing a formal specification for org-mode in the EBN form. Any proof that org-parser works? Indeed, there is the celebrated organice which is built on top of it. Kudos for 200ok-ch!
-
Casual Parsing in JavaScript
You might enjoy checking out Instaparse, a Clojure library. Its project page reads, “What if context-free grammars were as easy to use as regular expressions?”
It’s not over-promising, either. I went from never having heard of it before to getting complete and correct parse trees of some ancient JSP Expression Language in about 20 minutes. Most of that time was spent typing in the BNF description that I could find only in an image.
https://github.com/Engelberg/instaparse
-
Parsing Tools
Instaparse sounds pretty close to what you're looking for assuming you're ok being limited to context-free grammars.
-
I toyed with some ideas from various languages and concocted a Frankenstein which might not live for long. Come see and critique!
It is in EBNF, with some alternate conventions. It follows the syntax found in here, which I think is pretty easy to get behind.
-
Advent of Code 2020 Day 19 Monster Messages in Clojure (rest vs. next, empty sequence vs. nil)
Another way to solve it is to load the grammar directly into instaparse, specify the start rule :0 and count the successful applications of the parser to the messages:
What are some alternatives?
coalton - Coalton is an efficient, statically typed functional programming language that supercharges Common Lisp.
parser - String parser combinators
enso - Hybrid visual and textual functional programming.
chumsky - Write expressive, high-performance parsers with ease.
perl5 - 🐪 The Perl programming language
tree-sitter-org - Org grammar for tree-sitter
roast - 🦋 Raku test suite
parser-combinators - Parser combinators.
langs
rosie
hubtodate - Automatically fetches and updates repositories from GitHub
yieldparser - Parse using JavaScript generator functions — it’s like components but for parsing!