Talk:Comparison of parser generators

message: I marked the article as confusing because I made a parser generator and would like to add it to the list, but some of the columns are so unclear that I'm not sure what to put in them!
* I suspect "Grammar, code" answers the question "Are actions associated with the grammar mixed or separate from the grammar?" right?
* I imagine that the "Lexer" column is supposed to indicate whether the parser generator generates lexers and parsers or just parsers, but perhaps it would make more sense to have two "yes/no" columns, "generates parsers?" and "generates lexers?". As it is, there are three values, "none", "generated" and "external" and I have no idea what the difference is between "generated" and "external".
* I suppose that "IDE" either means "the parser generator has its own dedicated IDE" or "the parser generator integrates with one or more IDEs". Certainly this should not be a yes/no column: it should say whether the tool has a dedicated IDE, and if it integrates with an IDE it should specify which IDE.
* The "input grammar notation" seems weird in that ANTLR is marked "EBNF", but ANTLR syntax is definitely different than the EBNF described on Wikipedia. Since ANTLR is so popular I'm inclined to say that we simply refer to the notation as simply "ANTLR".
* The "parsing algorithm" seems to conflate two different issues: the input grammar type (e.g. LALR(1), LL(k), PEG) versus the parsing technique (e.g. table-driven, runtime-stack recursive-descent, packrat). In the "Deterministic context-free languages" section, "parsing algorithm" seems to state the input grammar type, but in the "Parsing expression grammars" section, the grammar type is presumably "PEG" so this column specifies the parsing technique instead. Perhaps it's reasonable to have both in a single column, but let's be clear that grammar type and parsing algorithm are two different things.
I request that someone who understands these tables well should clarify them by using better column names (e.g. IDE integration instead of just "IDE") and by adding explanatory paragraphs or bullet points above or below the table. I'd also suggest merging the "Deterministic context-free languages" and "Parsing expression grammars" since both are used for parsing computer languages. I'm guessing that "General context-free, conjunctive or boolean languages" is more for natural language processing so it's probably reasonable to have a separate table; in any case, it is non-obvious what the difference between the sections are; descriptive text and links to other Wikipedia articles are needed. Finally, I think that either (A) there should an extra column for special features of the parser generator, e.g. ANTLR's gated predicates or tree parsing, which go "above and beyond" the capabilities of grammar types like LL(k) in the theoretical literature, or (B) the "grammar type" column could mention the special features (e.g. LL(*) + syntactic/semantic predicates). 66.11.82.73 (talk) 23:18, 19 March 2014 (UTC)
thread_title:  "Confusing" 

message: Where would Perl's Parse::RecDescent be in those tables? I'd add it but I'm not confident enough in my compilers chops. It is documented at http://search.cpan.org/~jtbraun/Parse-RecDescent-1.967009/lib/Parse/RecDescent.pm
JidGom (talk) 17:32, 4 December 2013 (UTC)
thread_title:  Perl Parse::RecDescent 

message: Due to the fact that the article now contains also a list of parser generators for regular languages, I suggest to merge the article with List of C Sharp lexer generators. --Hyperyl (talk) 22:54, 24 December 2008 (UTC)
replies: text: --ebraminiotalk 09:23, 18 December 2010 (UTC)
thread_title:  Merge 

message: This discussion page needs to be cleaned up, the mentioned issues were resolved!--Hyperyl 13:49, 11 November 2007 (UTC)
thread_title: Old Discussion

message: Q: How is here the Definition of Grammar/code: Mixed or Separated. Separated from Code (without Code inside) or as independent File? 129.69.189.32 20:56, 12 October 2006 (UTC)
thread_title: Definitions

message: This chart needs much more explanation. I.e. adding wiki-links to LALR, etc, what does "sepperated" and "mixed" mean (per above), etc, etc, etc... —The preceding unsigned comment was added by 71.70.210.188 (talk) 00:09, 11 December 2006 (UTC)
thread_title:  Explanation 

message: Hi, I propose to change the title of this article to List of Parser Generators. This article is about parser generators and not about parsers, isn't it?eboy 15:55, 31 August 2007 (UTC)
replies: text: Excellent point. Originally, the article was titled "List of Compiler-Compilers", however, many items on the list are not compiler-compilers, including my project. I do agree that changing the title to "List of Parser Generators" or perhaps "List of Parser Development Software", would be useful. What is everyone's thoughts on the issue? --DevinCook 20:59, 1 September 2007 (UTC)
replies: text: Agreed, I like "List of Parser Generators" best. // Sping 20:24, 14 September 2007 (UTC)
thread_title:  Misleading article title 

message: In list are generators having Wiki page (ANTLR), having extenral link (ACCENT) and no having Wiki and external link (Grammatica). My proposal is new column with extenral link; this givs advantages:
:direct go to generator home page, irrespective if generator has Wiki page or not
:instantly can be seen (by color) if generator has Wiki page or not
--Borneq 08:11, 18 October 2007 (UTC)
thread_title:  Column with external link 

message: I suggest to remove the links to the websites of the parser generators, because it looks ugly and duplicates the efforts of the article pages (if present) which already list it.
So I propose to link the names of the parser generator that don't have a Wikipedia article to their websites.  —Preceding unsigned comment added by Hyperyl (talk • contribs) 23:01, 24 December 2008 (UTC)
replies: text: Sounds like a good idea.  Most of the data on this page is from non-notable programs, mostly added by their respective developers Tedickey (talk) 17:59, 15 May 2010 (UTC)
thread_title:  Remove website links 

message: Recent edits have added "Waxeye", which (see google "waxeye parser") appears to be non-notable. Tedickey (talk) 10:27, 30 December 2008 (UTC)
replies: text: For context, most of the google hits on "waxeye" itself refer to a bird.  The program has a few hundred hits, which is a few orders of magnitude less common than one would expect for a Wikipedia topic. Tedickey (talk) 10:28, 30 December 2008 (UTC)
thread_title:  non-notable Waxeye program 

message: How sure are you that Yacc++ is LR(k)/LALR(k). k seems to imply that it has unbounded lookahead, but as far as I can tell from the website's overview page, Yacc++ is LR(1)/LALR(1). Errantkid (talk) 21:47, 28 January 2009 (UTC)
replies: text: I'm changing it. Please if someone disagrees let us know Errantkid (talk) 21:09, 11 June 2009 (UTC)
thread_title:  Is Yacc++ really LR(k)/LALR(k)? 

message: I think it would be the best to replace all "LL(1)"s and "Recursive Descent"s with LL(1).
--Chricho (talk) 20:22, 9 March 2010 (UTC)
thread_title:  LL(1) = Recursive Descent 

message: Should CFG be replaced with “deterministic CFG”? --Chricho (talk) 18:47, 3 December 2010 (UTC)
thread_title:  GLR is for CFGs 

message: Redlink cleanup removed the following information contained in the link name or non-existent article title.  It might be reintegrated, for example, the fact that Narwhale is parser generator, Packrat is a library, and what GDK stands for.
Acronyms
* Grammar Deployment Kit|GDK
* LALR Parser Generator|LPG
* Lexical Analyzer and Parser Generator|Lapg
Libraries
* Parsing Expression Grammar Template Library|PEGTL
* Parsnip Parser Library|Parsnip
* Frisby (library)|Frisby
* Packrat (library)|Packrat
Lexers
* Turbo Pascal Lex/Yacc|TP Yacc
* Alex (lexer generator)|Alex
* Dolphin (lexer generator)|Dolphin
* DFA (lexer generator)|LRSTAR
Parsers
* Msta parser|Msta
* Laja (parser and code generator)|Laja
* Laja (parser and code generator)|Laja
* APG (parser generator)|APG
* Aurochs (parser generator)|Aurochs
* Austenx (parser generator)|AustenX
* AustenX (parser generator)|AustenX
* Beaver (parser generator)|Beaver
* CSP (parser generator)|CSP
* CUP (parser generator)|CUP
* Dragon (parser generator)|Dragon
* Dypgen (parser generator)|Dypgen
* eli (parser generator)|eli
* Elkhound (parser generator)|Elkhound
* jay (parser generator)|jay
* Lime (parser generator)|Lime
* LISA (parser generator)|LISA
* Menhir (parser generator)|Menhir
* Monkey (parser generator)|Monkey
* Narwhal (parser generator)|Narwhal
* peg (parser generator)|peg
* SLK (parser generator)|SLK
* SPARK (parser generator)|SPARK
* Styx (parser generator)|Styx
* Tap (parser generator)|Tap
* Tom (parser generator)|Tom
* Waxeye (parser generator)|Waxeye
* Whale (parser generator)|Whale
* Wisent (parser generator)|Wisent
* Yard (parser generator)|Yard
* Happy (Parser)|Happy
* Parsec (parser)|Parsec
* Sprache (parser)|Sprache
Programming Language and software
* Katadhin (programming language)|Katahdin
* Essence (software)|Essence
* Treetop (software)|Treetop
— CpiralCpiral 16:51, 8 September 2013 (UTC)
replies: text: That's problematic: most of the content for this topic lists nonnotable programs of little interest to anyone except those who added the external links (likely their developers). TEDickey (talk) 17:24, 8 September 2013 (UTC)
thread_title:  Redlink information 

message: Packrat has O(N) execution time, but with PEG.js you can easily verify O(N^2) execution time with the grammar:
 S = ( X / . )*
 X = "a" [ab]* "b"
Running this with cache enabled with a long string of "a" characters will give O(N^2) execution time. There is a misconception that any recursive descent parser with memoization is a packrat parser. That's not the case: a packrat parser achieves O(N) execution time by memoizing the result of every subexpression at every character position, including recursively unrolling repetition operators. PEG.js merely caches the result of the entire rule X.
Probably a lot of the parsers labelled "packrat" in this table are not really packrat, but I will just change the PEG.js one for now. I will call it a recursive descent parser, which is a reasonable approximation, it's also the term the author uses   -- Tim Starling (talk) 00:53, 4 June 2015 (UTC)
thread_title:  PEG.js is not packrat 

message: Along the same lines as what Tim Starling writes above, I have confirmed that OMeta is also not fully packrat.  CF 2.2.3 "A Note on Memoization" on page 41 of http://www.vpri.org/pdf/tr2008003_experimenting.pdf .  It is currently labeled in the table as "Packrat (modified)".  I propose that we standardize on a parenthetical, such as "(selective)" which is also used to describe several other parser generators, to describe these common variants on packrat parsing, rather than fall all the way back to the generic "Recursive descent". C. Scott Ananian (talk) 17:28, 18 June 2015 (UTC)
thread_title:  OMeta is not packrat 

message: I think that modern parser generators should include a GUI, this way it would be so easier to understand the parsing (and the parser generation) algorithms, thus allowing to create better parser more easily.
So the big question is : do they ALL lack a (good, intuitive, helping) GUI ???
78.227.78.135 (talk) 21:54, 9 November 2015 (UTC)
thread_title:  do they all lack a GUI (Graphical User Interface) ? 

message: The MIT license explicitly grants broad rights to use and redistribute the software:
    Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to *use, copy, modify, merge, publish, distribute, sublicense, and/or sell* copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
This broad grant of rights is what it means to most people for a license to be "MIT-like".
The SLK license doesn't do this:
    The License grants you the right to use the Product for the purposes of evaluating, designing, developing, and testing software products, provided that you agree to indemnify, hold harmless, and defend the supplier of the Product from and against any claims or lawsuits, including attorney's fees, that arise or result from the use or distribution of your software product.
I'm not sure what the authors of the SLK license really intended, but on the face of it this license appears to be far more restrictive than the MIT license. My (non-lawyer) interpretation of this license is that it probably intends to allow you to download the software and use it as-is but not to modify it or redistribute it. Thus, I think calling the SLK license "MIT-like" is misleading, and I'm removing that statement from the chart.
I'll note that the comparison with the MIT license doesn't seem to come from the SLK project. I can't find any statements about their license on their website aside from the text of the license itself. I found at least one other page calling it "MIT-like" but they may have been using Wikipedia as their source.  — Preceding unsigned comment added by Nculwell (talk • contribs) 16:54, 27 March 2019 (UTC)
thread_title:  SLK parser generator's license is not MIT-like 

message: The two tables in this article are very indiscriminate, largely consisting of non-notable projects which have seen very little adoption, if any. I've begun a review of the table for "Deterministic context-free languages". If anyone would like to assist, please continue working through this table, adding citations to reliable secondary sources, and deleting rows if none can be found. Entries don't necessarily need to meet the General Notability Guidelines and worth standalone articles, but they should have at least one reliable secondary source describing them (and not in passing). StereoFolic (talk) 18:22, 16 September 2023 (UTC)
thread_title:  Notability review