What Is Parsing Data
What is data parsing? – ScrapingBee
●
07 June, 2021
10 min read
Kevin worked in the web scraping industry for 10 years before co-founding ScrapingBee. He is also the author of the Java Web Scraping Handbook.
Data parsing is the process of taking data in one format and transforming it to another format. You’ll find parsers used everywhere. They are commonly used in compilers when we need to parse computer code and generate machine code.
This happens all the time when developers write code that gets run on hardware. Parsers are also present in SQL engines. SQL engines parse a SQL query, execute it, and return the results.
In the case of web scraping, this usually happens after data has been extracted from a web page via web scraping. Once you’ve scraped data from the web, the next step is making it more readable and better for analysis so that your team can use the results effectively.
A good data parser isn’t constrained to particular formats. You should be able to input any data type and output a different data type. This could mean transforming raw HTML into a JSON object or they might take data scraped from JavaScript rendered pages and change that into a comprehensive CSV file.
Parsers are heavily used in web scraping because the raw HTML we receive isn’t easy to make sense of. We need the data changed into a format that’s interpretable by a person. That might mean generating reports from HTML strings or creating tables to show the most relevant information.
Even though there are multiple uses for parsers, the focus of this blog post will be about data parsing for web scraping because it’s an online activity that thousands of people handle every day.
How to build a data parser
Regardless of what type of data parser you choose, a good parser will figure out what information from an HTML string is useful and based on pre-defined rules. There are usually two steps to the parsing process, lexical analysis and syntactic analysis.
Lexical analysis is the first step in data parsing. It basically creates tokens from a sequence of characters that come into the parser as a string of unstructured data, like HTML. The parser makes the tokens by using lexical units like keywords and delimiters. It also ignores irrelevant information like whitespaces and comments.
After the parser has separated the data between lexical units and the irrelevant information, it discards all of the irrelevant information and passes the relevant information to the next step.
The next part of the data parsing process is syntactic analysis. This is where parse tree building happens. The parser takes the relevant tokens from the lexical analysis step and arranges them into a tree. Any further irrelevant tokens, like semicolons and curly braces, are added to the nesting structure of the tree.
Once the parse tree is finished, then you’re left with relevant information in a structured format that can be saved in any file type. There are several different ways to build a data parser, from creating one programmatically to using existing tools. It depends on your business needs, how much time you have, what your budget is, and a few other factors.
To get started, let’s take a look at HTML parsing libraries.
HTML parsing libraries
HTML parsing libraries are great for adding automation to your web scraping flow. You can connect many of these libraries to your web scraper via API calls and parse data as you receive it.
Here are a few popular HTML parsing libraries:
Scrapy or BeautifulSoup
These are libraries written in Python. BeautifulSoup is a Python library for pulling data out of HTML and XML files. Scrapy is a data parser that can also be used for web scraping. When it comes to web scraping with Python, there are a lot of options available and it depends on how hands-on you want to be.
Cheerio
If you’re used to working with Javascript, Cheerio is a good option. It parses markup and provides an API for manipulating the resulting data structure. You could also use Puppeteer. This can be used to generate screenshots and PDFs of specific pages that can be saved and further parsed with other tools. There are many other JavaScript-based web scrapers and web parsers.
JSoup
For those that work primarily with Java, there are options for you as well. JSoup is one option. It allows you to work with real-world HTML through its API for fetching URLs and extracting and manipulating data. It acts as both a web scraper and a web parser. It can be challenging to find other Java options that are open-source, but it’s definitely worth a look.
Nokogiri
There’s an option for Ruby as well. Take a look at Nokogiri. It allows you to work with HTML and HTML with Ruby. It has an API similar to the other packages in other languages that lets you query the data you’ve retrieved from web scraping. It adds an extra layer of security because it treats all documents as untrusted by default. Data parsing in Ruby can be tricky as it can be harder to find gems you can work with.
Regular expression
Now that you have an idea of what libraries are available for your web scraping and data parsing needs, let’s address a common issue with HTML parsing, regular expressions. Sometimes data isn’t well-formatted inside of an HTML tag and we need to use regular expressions to extract the data we need.
You can build regular expressions to get exactly what you need from difficult data. Tools like regex101 can be an easy way to test out whether you’re targeting the correct data or not. For example, you might want to get your data specifically from all of the paragraph tags on a web page. That regular expression might look something like this:
/
(. *)<\/p>/
The syntax for regular expressions changes slightly depending on which programming language you’re working with. Most of the time, if you’re working with one of the libraries we listed above or something similar, you won’t have to worry about generating regular expressions.
If you aren’t interested in using one of those libraries, you might consider building your own parser. This can be challenging, but potentially worth the effort if you’re working with extremely complex data structures.
Building your own parser
When you need full control over how your data is parsed, building your own tool can be a powerful option. Here are a few things to consider before building your own parser.
A custom parser can be written in any programming language you like. You can make it compatible with other tools you’re using, like a web crawler or web scraper, without worrying about integration issues.
In some cases, it might be cost-effective to build your own tool. If you already have a team of developers in-house, it might not too big of a task for them to accomplish.
You have granular control over everything. If you want to target specific tags or keywords, you can do that. Any time you have an update to your strategy, you won’t have many problems with updating your data parser.
Although on the other hand, there are a few challenges that come with building your own parser.
The HTML of pages is constantly changing. This could become a maintenance issue for your developers. Unless you foresee your parsing tool becoming of huge importance to your business, taking that time from product development might not be effective.
It can be costly to build and maintain your own data parser. If you don’t have a developer team, contracting the work is an option but that could lead to step bills based on developers’ hourly rates. There’s also the cost of ramping up developers that are new to the project as they figure out how things work.
You will also need to buy, build, and maintain a server to host your custom parser on. It has to be fast enough to handle all of the data that you send through it or else you might run into issues with parsing data consistently. You’ll also have to make sure that server stays secure since you might be parsing sensitive data.
Having this level of control can be nice if data parsing is a big part of your business, otherwise, it could add more complexity than is necessary. There are plenty of reasons for wanting a custom parser, just make sure that it’s worth the investment over using an existing tool.
Parsing meta data
There’s also another way to parse web data through a website’s schema. Web schema standards are managed by, a community that promotes schema for structured data on the web. Web schema is used to help search engines understand information on web pages and provide better results.
There are many practical reasons people want to parse schema metadata. For example, companies might want to parse schema for an e-commerce product to find updated prices or descriptions. Journalists could parse certain web pages to get information for their news articles. There are also website that might aggregate data like recipes, how-to guides, and technical articles.
Schema comes in different formats. You’ll hear about JSON-LD, RDFa, and Microdata schema. These are the formats you’ll likely be parsing.
JSON-LD is JavaScript Object Notation for Linked Data. This is made of multi-dimensional arrays. It’s implemented using the standards in terms of SEO. JSON-LD is generally more simple to implement because you can paste the markup directly in an HTML document.
RDFa (Resource Description Framework in Attributes) is recommended by the World Wide Web Consortium (W3C). It’s used to embed RDF statements in XML and HTML. One big difference between this and the other schema types is that RDFa only defines the metasyntax for semantic tagging.
Microdata is a WHATWG HTML specification that’s used to nest metadata inside existing content on web pages. Microdata standards allow developers to design a custom vocabulary or use others like
All of these schema types are easily parsable with a number of tools across different languages. There’s a library from ScrapingHub, another from RDFLib.
We’ve covered a number of existing tools, but there are other great services available. For example, the ScrapingBee Google Search API. This tool allows you to scrape search results in real-time without worrying about server uptime or code maintainance. You only need an API key and a search query to start scraping and parsing web data.
There are many other web scraping tools, like JSoup, Puppeteer, Cheerio, or BeautifulSoup.
A few benefits of purchasing a web parser include:
Using an existing tool is low maintenance.
You don’t have to invest a lot of time with development and configurations.
You’ll have access to support that’s trained specifically to use and troubleshoot that particular tool.
Some of the downsides of purchasing a web parser include:
You won’t have granular control over everything the way your parser handles data. Although you will have some options to choose from.
It could be an expensive upfront cost.
Handling server issues will not be something you need to worry about.
Final thoughts
Parsing data is a common task handling everything from market research to gathering data for machine learning processes. Once you’ve collected your data using a mixture of web crawling and web scraping, it will likely be in an unstructured format. This makes it hard to get insightful meaning from it.
Using a parser will help you transform this data into any format you want whether it’s JSON or CSV or any data store. You could build your own parser to morph the data into a highly specified format or you could use an existing tool to get your data quickly. Choose the option that will benefit your business the most.
What Is Parsing of Data? – Blog | Oxylabs
If you work with development (whether part of the team or work in a company where you need to communicate with the tech team often), you’ll most likely come across the term data parsing. Simply put, it’s a process when one data format is transformed into another, more readable data format. But that’s a rather straightforward explanation.
In this article we’ll dig a little deeper on what is parsing of data, and discuss whether building an in-house data parser is more beneficial to a business, or is it better to buy a data extraction solution that already does the parsing for you.
What is data parsing?
Data parsing is a widely used method for data structuring; thus, you may discover many different descriptions while trying to find out what exactly it is. To make understanding this concept easier, we’ve put it into a simple definition.
What is data parsing? Data parsing is a method where one string of data gets converted into a different type of data. So let’s say you receive your data in raw HTML, a parser will take the said HTML and transform it into a more readable data format that can be easily read and understood.
What does a parser do?
A well-made parser will distinguish which information of the HTML string is needed, and in accordance to the parsers pre-written code and rules, it will pick out the necessary information and convert it into JSON, CSV or a table, for example.
It’s important to mention that a parser itself is not tied to a data format. It’s a tool that converts one data format into another, how it converts it and into what depends on how the parser was built.
Parsers are used for many technologies, including:
Java and other programming languagesHTML and XMLInteractive data language and object definition languageSQL and other database languagesModeling languagesScripting languagesHTTP and other internet protocols
To build or to buy?
Now, when it comes to the business side of things, an excellent question to ask yourself is, “Should my tech team build their own parser, or should we simply outsource? ”
As a rule of thumb, it’s usually cheaper to build your own, rather than to buy a premade tool. However, this isn’t an easy question to answer, and a lot more things should be taken into consideration when deciding to build or to buy.
Let’s look into the possibilities and outcomes with both options.
Building a data parser
Let’s say you decide to build your own parser. There are a few distinct benefits if making this decision:
A parser can be anything you like. It can be tailor-made for any work (parsing) you require. It’s usually cheaper to build your own ’re in control whatever decisions need to be made when updating and maintaining your parser.
But, like with anything, there’s always a downside of building your own parser:
You’ll need to hire and train a whole in-house team to build the intaining the parser is necessary – meaning more in house expenses and time resources ’ll need to buy and build a server that will be fast enough to parse your data in the speed you in control isn’t necessarily easy or beneficial – you’ll need to work closely with the tech team to make the right decisions to create something good, spending a lot of your time planning and testing.
Building your own has its benefits – but it takes a lot of your resources and time. Especially if you need to develop a sophisticated parser for parsing large volumes. That will require more maintenance and human resources, and valuable human resources because building one will require a highly-skilled developer team.
Buying a data parser
So what about buying a tool that parses your data for you? Let’s start with the benefits:
You won’t need to spend any money on human resources, as everything will be done for you, including maintaining the parser and the issues that arise will be solved a lot faster, as the people you buy your tools from have extensive know-how and are familiarized with their technology. It’s also less likely that the parser will crash or experience issues in general, as it will be tested and perfected to fit the markets’ requirements. You’ll save a lot on human resources and your own time, as the decision making on how to build the best parser will come from the outsourcing.
Of course, there are a few downsides to buying a parser as well:
It will be slightly more won’t have too much control over it.
Now, it seems that there are a lot of benefits to simply just buy one. But one thing that might make things easier to choose is to consider what sort of parser you’ll need. An expert developer can make an easy parser probably within a week. But if it’s a complex one, it can take months – that’s a lot of time, and resources.
It also falls to whether you’re a big business that has a lot of time and resources on their hands to build and maintain a parser. Or you’re a smaller business that needs to get things done to be able to grow within the market.
How we do it: Real-Time Crawler
Here at Oxylabs, we have a data gathering tool called Real-Time Crawler. This product is specifically built to scrape search engines and e-commerce websites on a large scale. We covered what Real-Time Crawler is and how it works in great detail in one of our articles, so make sure to check it out. Also, here’s a video below:
But why are we bringing up this tool? Well, Real-Time Crawler not only gathers the data – it also has a built-in parser that turns your HTML into JSON. If you choose to use Real-Time Crawler Callback method, after every job request, you’ll be provided with a URL to download the results in HTML or parsed JSON format.
Our built-in parser handles quite a lot of data daily. On February, 12 billion requests were made! And that’s back in February! Based on our 2019, Q1 statistics, the total requests grew by 7. 02% in comparison to Q4 2018. And these numbers continue to rise in accordance in Q2, 2019.
Our tech team has been working with this project for a few years now, and having this much experience we can say with confidence that the parser we built can handle any volume of data one might request.
So – to build or to buy? Well, building several years of experience, improvements, and maintenance of a tool that does its job to perfection – honestly, quite expensive.
Wrapping up
Hopefully, now you have a decent understanding of what is parsing of data. Taking everything into account, keep in mind whether you’re building a very sophisticated parser or not. If you are parsing large volumes of data, you will need good developers on your team to develop and maintain the parser. But, if you need a less complicated, smaller parser – probably best to build your own.
Also be mindful if you are a large company with a lot of resources, or a smaller one, that needs the right tools to keep things growing.
Oxylabs’ clients have significantly increased growth with Real-Time Crawler! If you are also looking for ways to improve your business, register here to start using our tools. Also, if you have more questions about data parsing, book a call with our sales team!
People also ask
What tools are required for data parsing?
After web scraping tools provide the required data, there are several options for data parsing. BeautifulSoup and LXML are two commonly used data parsing tools.
How to use a data parser?
Every data parsing tool will come with its own manual. Most of them will require some technical knowledge such as understanding Python and data from a web scraper.
What is data scraping?
Data scraping is the process of acquiring large amounts of data from the web through the use of automation and rotating IP address.
Gabija Fatenaite is a Product Marketing Manager at Oxylabs. Having grown up on video games and the internet, she grew to find the tech side of things more and more interesting over the years. So if you ever find yourself wanting to learn more about proxies (or video games), feel free to contact her – she’ll be more than happy to answer you.
All information on Oxylabs Blog is provided on an “as is” basis and for informational purposes only. We make no representation and disclaim all liability with respect to your use of any information contained on Oxylabs Blog or any third-party websites that may be linked therein. Before engaging in scraping activities of any kind you should consult your legal advisors and carefully read the particular website’s terms of service or receive a scraping license.
Parsing – Wikipedia
Parsing, syntax analysis, or syntactic analysis is the process of analyzing a string of symbols, either in natural language, computer languages or data structures, conforming to the rules of a formal grammar. The term parsing comes from Latin pars (orationis), meaning part (of speech). [1]
The term has slightly different meanings in different branches of linguistics and computer science. Traditional sentence parsing is often performed as a method of understanding the exact meaning of a sentence or word, sometimes with the aid of devices such as sentence diagrams. It usually emphasizes the importance of grammatical divisions such as subject and predicate.
Within computational linguistics the term is used to refer to the formal analysis by a computer of a sentence or other string of words into its constituents, resulting in a parse tree showing their syntactic relation to each other, which may also contain semantic and other information (p-values). [citation needed] Some parsing algorithms may generate a parse forest or list of parse trees for a syntactically ambiguous input. [2]
The term is also used in psycholinguistics when describing language comprehension. In this context, parsing refers to the way that human beings analyze a sentence or phrase (in spoken language or text) “in terms of grammatical constituents, identifying the parts of speech, syntactic relations, etc. “[1] This term is especially common when discussing what linguistic cues help speakers to interpret garden-path sentences.
Within computer science, the term is used in the analysis of computer languages, referring to the syntactic analysis of the input code into its component parts in order to facilitate the writing of compilers and interpreters. The term may also be used to describe a split or separation.
Human languages[edit]
Traditional methods[edit]
The traditional grammatical exercise of parsing, sometimes known as clause analysis, involves breaking down a text into its component parts of speech with an explanation of the form, function, and syntactic relationship of each part. [3] This is determined in large part from study of the language’s conjugations and declensions, which can be quite intricate for heavily inflected languages. To parse a phrase such as ‘man bites dog’ involves noting that the singular noun ‘man’ is the subject of the sentence, the verb ‘bites’ is the third person singular of the present tense of the verb ‘to bite’, and the singular noun ‘dog’ is the object of the sentence. Techniques such as sentence diagrams are sometimes used to indicate relation between elements in the sentence.
Parsing was formerly central to the teaching of grammar throughout the English-speaking world, and widely regarded as basic to the use and understanding of written language. However, the general teaching of such techniques is no longer current. [citation needed]
Computational methods[edit]
In some machine translation and natural language processing systems, written texts in human languages are parsed by computer programs. [4] Human sentences are not easily parsed by programs, as there is substantial ambiguity in the structure of human language, whose usage is to convey meaning (or semantics) amongst a potentially unlimited range of possibilities but only some of which are germane to the particular case. [5] So an utterance “Man bites dog” versus “Dog bites man” is definite on one detail but in another language might appear as “Man dog bites” with a reliance on the larger context to distinguish between those two possibilities, if indeed that difference was of concern. It is difficult to prepare formal rules to describe informal behaviour even though it is clear that some rules are being followed. [citation needed]
In order to parse natural language data, researchers must first agree on the grammar to be used. The choice of syntax is affected by both linguistic and computational concerns; for instance some parsing systems use lexical functional grammar, but in general, parsing for grammars of this type is known to be NP-complete. Head-driven phrase structure grammar is another linguistic formalism which has been popular in the parsing community, but other research efforts have focused on less complex formalisms such as the one used in the Penn Treebank. Shallow parsing aims to find only the boundaries of major constituents such as noun phrases. Another popular strategy for avoiding linguistic controversy is dependency grammar parsing.
Most modern parsers are at least partly statistical; that is, they rely on a corpus of training data which has already been annotated (parsed by hand). This approach allows the system to gather information about the frequency with which various constructions occur in specific contexts. (See machine learning. ) Approaches which have been used include straightforward PCFGs (probabilistic context-free grammars), [6] maximum entropy, [7] and neural nets. [8] Most of the more successful systems use lexical statistics (that is, they consider the identities of the words involved, as well as their part of speech). However such systems are vulnerable to overfitting and require some kind of smoothing to be effective. [citation needed]
Parsing algorithms for natural language cannot rely on the grammar having ‘nice’ properties as with manually designed grammars for programming languages. As mentioned earlier some grammar formalisms are very difficult to parse computationally; in general, even if the desired structure is not context-free, some kind of context-free approximation to the grammar is used to perform a first pass. Algorithms which use context-free grammars often rely on some variant of the CYK algorithm, usually with some heuristic to prune away unlikely analyses to save time. (See chart parsing. ) However some systems trade speed for accuracy using, e. g., linear-time versions of the shift-reduce algorithm. A somewhat recent development has been parse reranking in which the parser proposes some large number of analyses, and a more complex system selects the best option. [citation needed] Semantic parsers convert texts into representations of their meanings. [9]
Psycholinguistics[edit]
In psycholinguistics, parsing involves not just the assignment of words to categories (formation of ontological insights), but the evaluation of the meaning of a sentence according to the rules of syntax drawn by inferences made from each word in the sentence (known as connotation). This normally occurs as words are being heard or read. Consequently, psycholinguistic models of parsing are of necessity incremental, meaning that they build up an interpretation as the sentence is being processed, which is normally expressed in terms of a partial syntactic structure. Creation of initially wrong structures occurs when interpreting garden-path sentences.
Discourse analysis[edit]
Discourse analysis examines ways to analyze language use and semiotic events. Persuasive language may be called rhetoric.
Computer languages[edit]
Parser[edit]
A parser is a software component that takes input data (frequently text) and builds a data structure – often some kind of parse tree, abstract syntax tree or other hierarchical structure, giving a structural representation of the input while checking for correct syntax. The parsing may be preceded or followed by other steps, or these may be combined into a single step. The parser is often preceded by a separate lexical analyser, which creates tokens from the sequence of input characters; alternatively, these can be combined in scannerless parsing. Parsers may be programmed by hand or may be automatically or semi-automatically generated by a parser generator. Parsing is complementary to templating, which produces formatted output. These may be applied to different domains, but often appear together, such as the scanf/printf pair, or the input (front end parsing) and output (back end code generation) stages of a compiler.
The input to a parser is often text in some computer language, but may also be text in a natural language or less structured textual data, in which case generally only certain parts of the text are extracted, rather than a parse tree being constructed. Parsers range from very simple functions such as scanf, to complex programs such as the frontend of a C++ compiler or the HTML parser of a web browser. An important class of simple parsing is done using regular expressions, in which a group of regular expressions defines a regular language and a regular expression engine automatically generating a parser for that language, allowing pattern matching and extraction of text. In other contexts regular expressions are instead used prior to parsing, as the lexing step whose output is then used by the parser.
The use of parsers varies by input. In the case of data languages, a parser is often found as the file reading facility of a program, such as reading in HTML or XML text; these examples are markup languages. In the case of programming languages, a parser is a component of a compiler or interpreter, which parses the source code of a computer programming language to create some form of internal representation; the parser is a key step in the compiler frontend. Programming languages tend to be specified in terms of a deterministic context-free grammar because fast and efficient parsers can be written for them. For compilers, the parsing itself can be done in one pass or multiple passes – see one-pass compiler and multi-pass compiler.
The implied disadvantages of a one-pass compiler can largely be overcome by adding fix-ups, where provision is made for code relocation during the forward pass, and the fix-ups are applied backwards when the current program segment has been recognized as having been completed. An example where such a fix-up mechanism would be useful would be a forward GOTO statement, where the target of the GOTO is unknown until the program segment is completed. In this case, the application of the fix-up would be delayed until the target of the GOTO was recognized. Conversely, a backward GOTO does not require a fix-up, as the location will already be known.
Context-free grammars are limited in the extent to which they can express all of the requirements of a language. Informally, the reason is that the memory of such a language is limited. The grammar cannot remember the presence of a construct over an arbitrarily long input; this is necessary for a language in which, for example, a name must be declared before it may be referenced. More powerful grammars that can express this constraint, however, cannot be parsed efficiently. Thus, it is a common strategy to create a relaxed parser for a context-free grammar which accepts a superset of the desired language constructs (that is, it accepts some invalid constructs); later, the unwanted constructs can be filtered out at the semantic analysis (contextual analysis) step.
For example, in Python the following is syntactically valid code:
The following code, however, is syntactically valid in terms of the context-free grammar, yielding a syntax tree with the same structure as the previous, but is syntactically invalid in terms of the context-sensitive grammar, which requires that variables be initialized before use:
Rather than being analyzed at the parsing stage, this is caught by checking the values in the syntax tree, hence as part of semantic analysis: context-sensitive syntax is in practice often more easily analyzed as semantics.
Overview of process[edit]
The following example demonstrates the common case of parsing a computer language with two levels of grammar: lexical and syntactic.
The first stage is the token generation, or lexical analysis, by which the input character stream is split into meaningful symbols defined by a grammar of regular expressions. For example, a calculator program would look at an input such as “12 * (3 + 4)^2” and split it into the tokens 12, *, (, 3, +, 4, ), ^, 2, each of which is a meaningful symbol in the context of an arithmetic expression. The lexer would contain rules to tell it that the characters *, +, ^, ( and) mark the start of a new token, so meaningless tokens like “12*” or “(3” will not be generated.
The next stage is parsing or syntactic analysis, which is checking that the tokens form an allowable expression. This is usually done with reference to a context-free grammar which recursively defines components that can make up an expression and the order in which they must appear. However, not all rules defining programming languages can be expressed by context-free grammars alone, for example type validity and proper declaration of identifiers. These rules can be formally expressed with attribute grammars.
The final phase is semantic parsing or analysis, which is working out the implications of the expression just validated and taking the appropriate action. [10] In the case of a calculator or interpreter, the action is to evaluate the expression or program; a compiler, on the other hand, would generate some kind of code. Attribute grammars can also be used to define these actions.
Types of parsers[edit]
The task of the parser is essentially to determine if and how the input can be derived from the start symbol of the grammar. This can be done in essentially two ways:
Top-down parsing – Top-down parsing can be viewed as an attempt to find left-most derivations of an input-stream by searching for parse trees using a top-down expansion of the given formal grammar rules. Tokens are consumed from left to right. Inclusive choice is used to accommodate ambiguity by expanding all alternative right-hand-sides of grammar rules. [11] This is known as the primordial soup approach. Very similar to sentence diagramming, primordial soup breaks down the constituencies of sentences. [12]
Bottom-up parsing – A parser can start with the input and attempt to rewrite it to the start symbol. Intuitively, the parser attempts to locate the most basic elements, then the elements containing these, and so on. LR parsers are examples of bottom-up parsers. Another term used for this type of parser is Shift-Reduce parsing.
LL parsers and recursive-descent parser are examples of top-down parsers which cannot accommodate left recursive production rules. Although it has been believed that simple implementations of top-down parsing cannot accommodate direct and indirect left-recursion and may require exponential time and space complexity while parsing ambiguous context-free grammars, more sophisticated algorithms for top-down parsing have been created by Frost, Hafiz, and Callaghan[13][14] which accommodate ambiguity and left recursion in polynomial time and which generate polynomial-size representations of the potentially exponential number of parse trees. Their algorithm is able to produce both left-most and right-most derivations of an input with regard to a given context-free grammar.
An important distinction with regard to parsers is whether a parser generates a leftmost derivation or a rightmost derivation (see context-free grammar). LL parsers will generate a leftmost derivation and LR parsers will generate a rightmost derivation (although usually in reverse). [11]
Some graphical parsing algorithms have been designed for visual programming languages. [15][16] Parsers for visual languages are sometimes based on graph grammars. [17]
Adaptive parsing algorithms have been used to construct “self-extending” natural language user interfaces. [18]
Parser development software[edit]
Some of the well known parser development tools include the following:
ANTLR
Bison
Coco/R
Definite clause grammar
GOLD
JavaCC
Lemon
Lex
LuZc
Parboiled
Parsec
Ragel
Spirit Parser Framework
Syntax Definition Formalism
SYNTAX
XPL
Yacc
PackCC
Lookahead[edit]
C program that cannot be parsed with less than 2 token lookahead. Top: C grammar excerpt. [19] Bottom: a parser has digested the tokens “int v;main(){” and is about choose a rule to derive Stmt. Looking only at the first lookahead token “v”, it cannot decide which of both alternatives for Stmt to choose; the latter requires peeking at the second token.
Lookahead establishes the maximum incoming tokens that a parser can use to decide which rule it should use. Lookahead is especially relevant to LL, LR, and LALR parsers, where it is often explicitly indicated by affixing the lookahead to the algorithm name in parentheses, such as LALR(1).
Most programming languages, the primary target of parsers, are carefully defined in such a way that a parser with limited lookahead, typically one, can parse them, because parsers with limited lookahead are often more efficient. One important change[citation needed] to this trend came in 1990 when Terence Parr created ANTLR for his Ph. D. thesis, a parser generator for efficient LL(k) parsers, where k is any fixed value.
LR parsers typically have only a few actions after seeing each token. They are shift (add this token to the stack for later reduction), reduce (pop tokens from the stack and form a syntactic construct), end, error (no known rule applies) or conflict (does not know whether to shift or reduce).
Lookahead has two advantages. [clarification needed]
It helps the parser take the correct action in case of conflicts. For example, parsing the if statement in the case of an else clause.
It eliminates many duplicate states and eases the burden of an extra stack. A C language non-lookahead parser will have around 10, 000 states. A lookahead parser will have around 300 states.
Example: Parsing the Expression 1 + 2 * 3[dubious – discuss]
Set of expression parsing rules (called grammar) is as follows,
Rule1:
E → E + E
Expression is the sum of two expressions.
Rule2:
E → E * E
Expression is the product of two expressions.
Rule3:
E → number
Expression is a simple number
Rule4:
+ has less precedence than *
Most programming languages (except for a few such as APL and Smalltalk) and algebraic formulas give higher precedence to multiplication than addition, in which case the correct interpretation of the example above is 1 + (2 * 3).
Note that Rule4 above is a semantic rule. It is possible to rewrite the grammar to incorporate this into the syntax. However, not all such rules can be translated into syntax.
Simple non-lookahead parser actions
Initially Input = [1, +, 2, *, 3]
Shift “1” onto stack from input (in anticipation of rule3). Input = [+, 2, *, 3] Stack = [1]
Reduces “1” to expression “E” based on rule3. Stack = [E]
Shift “+” onto stack from input (in anticipation of rule1). Input = [2, *, 3] Stack = [E, +]
Shift “2” onto stack from input (in anticipation of rule3). Input = [*, 3] Stack = [E, +, 2]
Reduce stack element “2” to Expression “E” based on rule3. Stack = [E, +, E]
Reduce stack items [E, +, E] and new input “E” to “E” based on rule1. Stack = [E]
Shift “*” onto stack from input (in anticipation of rule2). Input = [3] Stack = [E, *]
Shift “3” onto stack from input (in anticipation of rule3). Input = [] (empty) Stack = [E, *, 3]
Reduce stack element “3” to expression “E” based on rule3. Stack = [E, *, E]
Reduce stack items [E, *, E] and new input “E” to “E” based on rule2. Stack = [E]
The parse tree and resulting code from it is not correct according to language semantics.
To correctly parse without lookahead, there are three solutions:
The user has to enclose expressions within parentheses. This often is not a viable solution.
The parser needs to have more logic to backtrack and retry whenever a rule is violated or not complete. The similar method is followed in LL parsers.
Alternatively, the parser or grammar needs to have extra logic to delay reduction and reduce only when it is absolutely sure which rule to reduce first. This method is used in LR parsers. This correctly parses the expression but with many more states and increased stack depth.
Lookahead parser actions[clarification needed]
Shift 1 onto stack on input 1 in anticipation of rule3. It does not reduce immediately.
Reduce stack item 1 to simple Expression on input + based on rule3. The lookahead is +, so we are on path to E +, so we can reduce the stack to E.
Shift + onto stack on input + in anticipation of rule1.
Shift 2 onto stack on input 2 in anticipation of rule3.
Reduce stack item 2 to Expression on input * based on rule3. The lookahead * expects only E before it.
Now stack has E + E and still the input is *. It has two choices now, either to shift based on rule2 or reduction based on rule1. Since * has higher precedence than + based on rule4, we shift * onto stack in anticipation of rule2.
Shift 3 onto stack on input 3 in anticipation of rule3.
Reduce stack item 3 to Expression after seeing end of input based on rule3.
Reduce stack items E * E to E based on rule2.
Reduce stack items E + E to E based on rule1.
The parse tree generated is correct and simply more efficient[clarify][citation needed] than non-lookahead parsers. This is the strategy followed in LALR parsers.
See also[edit]
Backtracking
Chart parser
Compiler-compiler
Deterministic parsing
Generating strings
Grammar checker
LALR parser
Lexical analysis
Pratt parser
Shallow parsing
Left corner parser
Parsing expression grammar
DMS Software Reengineering Toolkit
Program transformation
Source code generation
References[edit]
^ a b “Parse”. Retrieved 27 November 2010.
^ Masaru Tomita (6 December 2012). Generalized LR Parsing. Springer Science & Business Media. ISBN 978-1-4615-4034-2.
^ “Grammar and Composition”.
^ Christopher D.. Manning; Christopher D. Manning; Hinrich Schütze (1999). Foundations of Statistical Natural Language Processing. MIT Press. ISBN 978-0-262-13360-9.
^ Jurafsky, Daniel (1996). “A Probabilistic Model of Lexical and Syntactic Access and Disambiguation”. Cognitive Science. 20 (2): 137–194. CiteSeerX 10. 1. 150. 5711. doi:10. 1207/s15516709cog2002_1.
^ Klein, Dan, and Christopher D. Manning. “Accurate unlexicalized parsing. ” Proceedings of the 41st Annual Meeting on Association for Computational Linguistics-Volume 1. Association for Computational Linguistics, 2003.
^ Charniak, Eugene. “A maximum-entropy-inspired parser. ” Proceedings of the 1st North American chapter of the Association for Computational Linguistics conference. Association for Computational Linguistics, 2000.
^ Chen, Danqi, and Christopher Manning. “A fast and accurate dependency parser using neural networks. ” Proceedings of the 2014 conference on empirical methods in natural language processing (EMNLP). 2014.
^ Jia, Robin; Liang, Percy (2016-06-11). “Data Recombination for Neural Semantic Parsing”. arXiv:1606. 03622 [].
^ Berant, Jonathan, and Percy Liang. “Semantic parsing via paraphrasing. ” Proceedings of the 52nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers). 2014.
^ a b Aho, A. V., Sethi, R. and Ullman, J. (1986) ” Compilers: principles, techniques, and tools. ” Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA.
^ Sikkel, Klaas, 1954- (1997). Parsing schemata: a framework for specification and analysis of parsing algorithms. Berlin: Springer. ISBN 9783642605413. OCLC 606012644. CS1 maint: multiple names: authors list (link)
^ Frost, R., Hafiz, R. and Callaghan, P. (2007) ” Modular and Efficient Top-Down Parsing for Ambiguous Left-Recursive Grammars. ” 10th International Workshop on Parsing Technologies (IWPT), ACL-SIGPARSE, Pages: 109 – 120, June 2007, Prague.
^ Frost, R., Hafiz, R. (2008) ” Parser Combinators for Ambiguous Left-Recursive Grammars. ” 10th International Symposium on Practical Aspects of Declarative Languages (PADL), ACM-SIGPLAN, Volume 4902/2008, Pages: 167 – 181, January 2008, San Francisco.
^ Rekers, Jan, and Andy Schürr. “Defining and parsing visual languages with layered graph grammars. ” Journal of Visual Languages & Computing 8. 1 (1997): 27-55.
^ Rekers, Jan, and A. Schurr. “A graph grammar approach to graphical parsing. ” Visual Languages, Proceedings., 11th IEEE International Symposium on. IEEE, 1995.
^ Zhang, Da-Qian, Kang Zhang, and Jiannong Cao. “A context-sensitive graph grammar formalism for the specification of visual languages. ” The Computer Journal 44. 3 (2001): 186-200.
^ Jill Fain Lehman (6 December 2012). Adaptive Parsing: Self-Extending Natural Language Interfaces. ISBN 978-1-4615-3622-2.
^ taken from Brian W. Kernighan and Dennis M. Ritchie (Apr 1988). The C Programming Language. Prentice Hall Software Series (2nd ed. ). Englewood Cliffs/NJ: Prentice Hall. ISBN 0131103628. (Appendix A. 13 “Grammar”, p. 193 ff)
21. Free Parse HTML Codes [1]
Further reading[edit]
Chapman, Nigel P., LR Parsing: Theory and Practice, Cambridge University Press, 1987. ISBN 0-521-30413-X
Grune, Dick; Jacobs, Ceriel J. H., Parsing Techniques – A Practical Guide, Vrije Universiteit Amsterdam, Amsterdam, The Netherlands. Originally published by Ellis Horwood, Chichester, England, 1990; ISBN 0-13-651431-6
External links[edit]
Look up parse or parsing in Wiktionary, the free dictionary.
The Lemon LALR Parser Generator
Stanford Parser The Stanford Parser
Turin University Parser Natural language parser for the Italian, open source, developed in Common Lisp by Leonardo Lesmo, University of Torino, Italy.
Short history of parser construction
