Talk:Parser combinator

Latest comment: 7 years ago by Dave Yost in topic Notation

Quote: "To keep the discussion relatively straight forward, we discuss parser combinators in terms of recognizer only" - this and other language looks like it is lifted straight out of an academic paper. Although this is a pretty rarefied subject perhaps some small edits would make this article sound slightly more like an encyclopedia, and less like a paper. I can't do it myself because I am far too ignorant on the subject to avoid changing the articles meaning in tandem with changing its style. 62.140.194.147 (talk) 14:19, 10 March 2010 (UTC)Reply

You can do the changes, just learn: what a combinator is, which is a little confusing in the article, and find some simple examples of parsers. Learn about the problem of left recursion, and you are done. Good lock! I wont do it by my self because I in other articles my collaborations were erased due to be not in the wikipedia style, looking more academic. See my protest bellow.

This article now actually explains what a parser combinator is and does, something I felt it was lacking previously. 87.115.114.221 (talk) 23:34, 24 September 2011 (UTC) It is not totally correct your definition, learn what a combinator is, they are not called combinators because they combine functions, read an authoritative book like Barendregt's lambda-calculus book. Any way thanks for your enthusiasm.Reply

I find this article fairly biased. Although I do not wish to diminish their achievements, the focus on Frost et al.'s research seems exaggerated and not suitable for an encyclopedia article. — Preceding unsigned comment added by Dominique.devriese (talkcontribs) 11:54, 18 June 2012 (UTC)Reply

No, Dominique, this subject is not about politics where a left or right wing bias is detectable.
Who wrote this article was worried about a problem that consist of a non terminating parsing, due to left recursion (that is computer science, so you do not have to worry about that bias).
The person who wrote the article learned it in an article that presents a way to avoid this problem. That is not bad. This article should be expanded to explain the combinators way to write parsers, the advantages and disadvantages. But that sounds to lengthily to many volunteers who mutilate the articles because they support the trend that wikipedia should have only short superficial articles. If you think you can judge an article like this as biased, write it your self, spend some time searching about the subject and write your own perfect article.

wikipedia is an encyclopedia not an illustrated dictionary edit

I wanted to make some changes in this article to make it more clear. A work I won't do, because guys who do not know about the subject, don't look it fine by ignorance of the subject, and based in very absurd dogmas, of what should a wikipedia article look like. A criteria which in infecting this site with the trend to give a very superficial treatment to every subject. An encyclopedia is not an illustrated dictionary, it should enclose all human knowledge. Before some wiki-policeperso, come to erase my colaboration, I will refrain to improve any article in a subject I know (like this one) until that emerging policy is eradicated from wikipedia. Sorry guys but I perceive as threat comments like: I see above as seeing this article as biased, just because the bibliography or that looks like a paper and not an encyclopedia entry. I will not spend my time to wait that the skilled wiki-police, that place alarms on pages they are watching, come to erase all new information in the subject as soon as I have entered it.

I had that experience several times. Now I just protest for that attitude which I suspect is paid by commercial encyclopedia competitors. And I have decided to warn my students to not trust in wikipedia, due to such pseudo-official vandalism, by self-named authorities. Stop that actions and I will come back again to improve, not to oversimplify the subjects I know about.

In functional programming? edit

The first sentence states that this idea is limited to functional programming, but several of the examples linked in the external links are to implementations that are not functional (e.g. the Java implementation of Parsec, which uses object composition as a replacement for first-class functions and monads). In general, the idea is not specific to functional programming, although it did originate in that field. I believe it should be changed to computer science rather than functional programming. Comments? 212.159.69.4 (talk) 14:30, 1 January 2016 (UTC)Reply

As the article states, a combinator is higher order function. I.e. parser combinators are specific to functional programming. They might have application outside of FP, but their use originated in FP, and they continue to be used predominantly there. JParsec might be inspired by Parsec but doesn't appear to actually use combinators. See also [1] - "In functional programming, a popular approach to building recursive descent parsers is to model parsers as functions, and to define higher-order functions (or combinators) that implement grammar constructions...".

____

Some parts of the article are now worse than the very first version edit

Some parts of the article are now worse than the very first version. In particular, the Basic idea section doesn't say anything useful for either the beginner or the expert, making it unhelpful for every reader. The brief mention of Wadler's contributions found in the initial version has been completely erased. This sentence as a whole doesn't make sense: "Parser combinators, like all recursive descent parsers, are not limited to the Context-free grammar and thus do no global search for ambiguities in the LL(k) parsing First(k) and Follow(k) sets." The last bit is true, but it's hard to understand what the editor is trying to convey with "are not limited to the cfg". Some of the other parts of the article are better. Quale (talk) 05:58, 14 June 2016 (UTC)Reply

Notation edit

I gather that there is a conventional notation, including operators like <*> and others. A section on this would be helpful. — Preceding unsigned comment added by Dave Yost (talkcontribs) 15:39, 27 October 2016 (UTC)Reply