51–60 of 91 posts
Earlier quoted context omitted.
For general-purpose languages, yes, but there are some exceptions. Ruby uses yacc, and Python uses a custom LL(1)-ish parser generator, which is in the process of being replaced by a custom PEG parser generator [0]. [0] https://github.com/gvanrossum/pegen
Ruby's yacc parser is my usual go-to for telling people how not to do it. That thing's terrifying.
Earlier quoted context omitted.
Second this. Recursive descent parsers are much easier in the long run, even if you can't immediately see your grammar after they have grown for a while.
I would agree but... From trying to understand parsing and RDPs I think I don't have the part of the brain required to understand it. Not that it isn't simple, it is. But it seems examples (as usual) overexplain the simple things then overlook something that seems obvious but isn't. The only time I managed to write a parser for simple math that wasn't an example was through the use of 'reverse production' parsing. Ye…
I manged to follow it when i was 14, when i found it on one of the newsgroups.
https://compilers.iecc.com/crenshaw/
here is port of code to C https://github.com/lotabout/Let-s-build-a-compiler
I tried to read this article, but unfortunately the lack of grammar was too distracting and I just couldn't get through it. A lot of these are things that Google Docs or Microsoft Word will notice and ask you to change. I highly recommend using one of those to write (especially if English is not your first language) and trying to understand the suggestions it makes. Your articles will come out much more readable to o…
Counterpoint: I used to "and I stopped reading" when I ran into grammar issues. I gradually realized that it's worth the effort to focus on the underlying ideas and evaluate that , rather than someone's 2nd language ability. People are smart, even when they talk funny, y'all. (The worth/validity of the underlying ideas is a separate matter.) Counterpoint 2: Automated grammar corrections are risky unless you're a nati…
Is it not the case that most serious parser implementations are hand-written? In part because it makes it so much easier to provide good diagnostic messages. I feel like every other project moves from parser-generators to hand-rolled parsers and levels.
What I don't like about any of these parsers, including ANTLR is that for real languages you get not a clear EBNF grammar, but terrible mix of declarative and imperative statements. I was pretty sure PEG is the modern way to go, but looks like it's not. So, what is then?
Is it not the case that most serious parser implementations are hand-written? In part because it makes it so much easier to provide good diagnostic messages. I feel like every other project moves from parser-generators to hand-rolled parsers and levels.
Is it not the case that most serious parser implementations are hand-written? In part because it makes it so much easier to provide good diagnostic messages. I feel like every other project moves from parser-generators to hand-rolled parsers and levels.
* https://github.com/antlr/antlr4/blob/master/doc/faq/general....
* See: "What do you think are the problems people will try to solve with ANTLR4?" question
I've used several different parser generators in the past. But I've also transitioned to hand-rolled recursive decent parsers, being Lazy I've created a library to assist in hand-rolling a recursive decent parser: https://github.com/SAP/chevrotain
"ANTLR instead is more actively developed. It has been re-written from scratch a few times during the years, so the code has is of good quality." ... rewrites improve code quality ... right ... right???
Is it not the case that most serious parser implementations are hand-written? In part because it makes it so much easier to provide good diagnostic messages. I feel like every other project moves from parser-generators to hand-rolled parsers and levels.
To put it another way, I'm rarely parsing data for it to be directly optimized into a machine language. I'm parsing data to extract parts I care about and then work with those parts. The more consistent this process is the easier it is to debug and fix. If my whole parsing/using-the-parsed-data pipeline is in the same language, say Javascript, then I am still only ever debugging the same language and runtime environment (eg: node v12 on whatever \*nix).
In a practical example, YARA[0] is (confusingly) used as both a format[1] and specific implementation[2] for sharing malware detection rules. ClamAV[3] is a popular open source antivirus engine that added YARA-the-format support a few years ago[4]. If you look at their grammar[5] file as well, you can see that one uses GNU Bison 3.0.4 the other uses 3.0.5. One is 3754 lines long, the other is 1849. We can expect these to behave differently. At a certain point, say because of how regular expressions are handled[6], it becomes easier to maintain your own parser than to deal with quirks/whims of someone else's implementation (generated or not).
[0]: https://en.wikipedia.org/wiki/YARA
[1]: https://yara.readthedocs.io/en/latest/writingrules.html
[2]: https://github.com/VirusTotal/yara/blob/master/libyara/hex_g...
[4]: https://blog.clamav.net/2015/06/clamav-099b-meets-yara.html
[5]: https://github.com/Cisco-Talos/clamav-devel/blob/898c08f08b5...
[6]: "In previous versions of YARA, external libraries like PCRE and RE2 were used to perform regular expression matching, but starting with version 2.0 YARA uses its own regular expression engine. This new engine implements most features found in PCRE, except a few of them" from https://yara.readthedocs.io/en/latest/writingrules.html#regu... ; if the regular expression grammar and/or symbol set isn't consistent the things parsing the files won't necessarily be either
"ANTLR instead is more actively developed. It has been re-written from scratch a few times during the years, so the code has is of good quality." ... rewrites improve code quality ... right ... right???
is that a copypasta error or verbatim? that statement itself could use a rewrite. irony at its best