Answers.Body: <p><strong>Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo</strong></p>
  <p><a href="https://en.m.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo_buffalo" rel="nofollow noreferrer">https://en.m.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo_buffalo</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-03T20:37:14.857Z
Answers.LastActivityDate: 2024-05-03T20:37:14.857Z
Answers.UserDisplayName: jonsen
Answers.Body: <p><strong>TLDR version:</strong> A parser scans a linear string of symbols, presumed to belong to some language, and it applies the <em>grammar rules</em> of the language to discover the <em>structure</em> of information that is encoded by the string.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-24T11:16:07.560Z
Answers.Text: How is that intelligible to someone to who it's unintelligible ?? [Sorry couldn't resist]
Answers.UserDisplayName: Rushi
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-24T12:03:25.450Z
Answers.Text: @Rushi, I guess I was looking back to a time in my own life when I would have understood words like "linear," and "grammar," and "structure," and "symbol;" but I had not ever heard of a software component called, "parser." I know some young people today who don't know the meanings of _any_ of those words. None of them has ever asked me what a parser does, and I don't expect that any of them ever will ask. If they do, I may have to politely decline.
Answers.UserDisplayName: Solomon Slow
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-24T12:05:26.203Z
Answers.Text: The thing is that a parser's 'symbols'  are very abstract -- they could be something called "IDENT" or "KEYWORD". This is unlikely to make sense to someone who doesnt understand the compiler toolchain
Answers.UserDisplayName: Rushi
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-24T12:08:38.523Z
Answers.Text: @Rushi, Well, I thought about that after I wrote my answer. I suppose that if I gave somebody my one sentence explanation (above,) and their eyes did not glaze over, and they asked for more; Then I might add that many parsers have a preliminary stage called "lexical analyzer," whose job is to group adjacent symbols into a linear stream of _tokens_ (a.k.a., "lexemes") and, to label each of them according to the role it plays in the grammar. I suppose I could go on from there until either (a) we have actually built a parser, or (b) their interest peters out.
Answers.UserDisplayName: Solomon Slow
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-24T12:12:06.757Z
Answers.Text: ... which is a "parser" in its own right!! Just that compiler writers dont usually call it that. From the computation theory pov a regular language is a context free language. And HecK! In the modern age the lexer may be preceded by a UTF8 "collector" which groups variable length UTF8 bytes into characters, which is an even more trivial lexer... therefore parser
Answers.UserDisplayName: Rushi
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-24T12:14:45.603Z
Answers.Text: IMHO teaching this toolchain should be part of an introductory CS1 course. But that is not meaningful for "industrial languages" like Python Java what have you. It is not so hard for scheme say, where the parser is available directly as the library call `read`
Answers.UserDisplayName: Rushi
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-24T16:46:59.037Z
Answers.Text: @Rushi, IMO, what defines a _mere_ lexical analyzer is that it mostly just finds the beginnings and ends of tokens. Its input is a linear sequence of low-level symbols, and its output is _the same linear sequence,_ but grouped into larger, higher-level, labelled chunks with some limited decoding (e.g., its usually the lexer's job to compute the values of numeric literal tokens.) If a "parsing" function does anything more sophisticated than, say, decoding string literals that are allowed to contain escape sequences or, deciding what's octal and what's decimal; then IMO it's more than a "lexer."
Answers.UserDisplayName: Solomon Slow
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-24T17:10:47.467Z
Answers.Text: This is all compiler writer knowledge. And we return to the OP question. And my 1st comment .  The non smiley comment would be *Its a good question; And I don't have v good answers*.  But I can say I e written toy compilers in a dozen lines. Also lexers. By using a haskell like language
Answers.UserDisplayName: Rushi
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-23T23:15:13.613Z
Answers.LastActivityDate: 2024-05-23T23:15:13.613Z
Answers.UserDisplayName: Solomon Slow
Answers.Body: <p>I think you have a pretty reasonable idea, though I have no idea why you would choose to use a Latin example.  Is your audience highly familiar with Latin?  If not, it is a distraction and a source of confusion.</p>
  <p>I've explained parsers for years to my classes.</p>
  <p>I would not start with human language.  I start with mathematics.  I say that the parser groups and interprets tokens or symbols (words) to show how they relate to one another.  And then I build a few little ASTs for some simple mathematical equations, such as <span class="math-container">$x = 4 + (3 * 2)$</span> and <span class="math-container">$x + 3 = (y - z) * 3$</span>.  I start with mathematical equations because most people are familiar with simple order of operations, and the tree that comes out is quite intuitive.</p>
  <p>If you are explaining this to a layperson (which lightly tugs at the question of <em>why</em>) who is a non-coder, you might then build a simple AST for a sentence in English (or whatever is the native language of the person you are explaining to.)</p>
  <p>But if you are speaking to someone with some CS background, I would move on to a short code example because they are more intuitive.  Something like:</p>
  <pre class="lang-java prettyprint-override"><code>int y = 5;
  int k = 4;
  k = k + y;
  </code></pre>
  <p>To be honest, I think that is enough to get the gist of the thing, and even enough for a fairly talented coder to take a crack at building a simple one themselves.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-06-25T20:54:39.267Z
Answers.Text: I might be sorry I AST :-)
Answers.UserDisplayName: Scott Rowe
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-01T01:32:03.537Z
Answers.LastActivityDate: 2024-05-01T01:32:03.537Z
Answers.UserDisplayName: Ben I.
Body: <p>Here is an explanation I came up with:</p>
  <p>Consider the following sentence from Caesar's De Bello Gallico (book 6, chapter 24): &quot;<i>Ea, quae fertilissima totius Germaniae sunt, loca aliquibus Graecis <b>nota</b> fama esse loquuntur.</i>&quot;. Which word is the word &quot;nota&quot; (known) syntactically connected to? If you know only a little bit of Latin, you will probably assume it is connected with &quot;fama&quot; (fame, rumour), that it is a pleonasm and that the word &quot;nota&quot; should be ignored. But that's incorrect. The word &quot;nota&quot; is connected to &quot;loca&quot; (places, locations). The sentence means: &quot;<i>They say that that those places, which are the most fertile of whole Germany, were known to some Greeks by rumours.</i>&quot;. When such situations happen in a programming language, the parser would connect &quot;nota&quot; and &quot;loca&quot; to be children of a single node in the abstract syntax tree. The parser is the part of the compiler or an interpreter which tells other parts of the compiler or an interpreter which word in a programming language is syntactically connected to which other word.</p>
  <p>What do you think about that explanation? Do you think there is a better one?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-06-25T20:52:22.100Z
Comments.Text: As an analogy to human language, I would say that it identifies the "parts of speech"  so that the input can be meaningfully translated or acted on.
Comments.UserDisplayName: Scott Rowe
Tags: <language-types>
Title: How would you explain to a layman what the parser (the part of the compiler or intepreter) is?
ThreadText: # How would you explain to a layman what the parser (the part of the compiler or intepreter) is?
  
  (Asked by: username_0 on 2024-04-30)
  
  Here is an explanation I came up with:
  
  Consider the following sentence from Caesar's De Bello Gallico (book 6, chapter 24): "*Ea, quae fertilissima totius Germaniae sunt, loca aliquibus Graecis **nota** fama esse loquuntur.*". Which word is the word "nota" (known) syntactically connected to? If you know only a little bit of Latin, you will probably assume it is connected with "fama" (fame, rumour), that it is a pleonasm and that the word "nota" should be ignored. But that's incorrect. The word "nota" is connected to "loca" (places, locations). The sentence means: "*They say that that those places, which are the most fertile of whole Germany, were known to some Greeks by rumours.*". When such situations happen in a programming language, the parser would connect "nota" and "loca" to be children of a single node in the abstract syntax tree. The parser is the part of the compiler or an interpreter which tells other parts of the compiler or an interpreter which word in a programming language is syntactically connected to which other word.
  
  What do you think about that explanation? Do you think there is a better one?
  
  **Tags:** language-types
  
  > **Comments:**
  > **username_1**: As an analogy to human language, I would say that it identifies the "parts of speech"  so that the input can be meaningfully translated or acted on.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_5 on 2024-05-01. Score: 6 | Accepted answer
  
  I think you have a pretty reasonable idea, though I have no idea why you would choose to use a Latin example. Is your audience highly familiar with Latin? If not, it is a distraction and a source of confusion.
  
  I've explained parsers for years to my classes.
  
  I would not start with human language. I start with mathematics. I say that the parser groups and interprets tokens or symbols (words) to show how they relate to one another. And then I build a few little ASTs for some simple mathematical equations, such as $x = 4 + (3 \* 2)$ and $x + 3 = (y - z) \* 3$. I start with mathematical equations because most people are familiar with simple order of operations, and the tree that comes out is quite intuitive.
  
  If you are explaining this to a layperson (which lightly tugs at the question of *why*) who is a non-coder, you might then build a simple AST for a sentence in English (or whatever is the native language of the person you are explaining to.)
  
  But if you are speaking to someone with some CS background, I would move on to a short code example because they are more intuitive. Something like:
  
  ```java
  int y = 5;
  int k = 4;
  k = k + y;
  
  ```
  
  To be honest, I think that is enough to get the gist of the thing, and even enough for a fairly talented coder to take a crack at building a simple one themselves.
  
  > **Comments:**
  > **username_1**: I might be sorry I AST :-)  
  
  ---
  
  ### Answer by username_2 on 2024-05-03. Score: 1
  
  **Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo**
  
  <https://en.m.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo_buffalo>
  
  
  ---
  
  ### Answer by username_3 on 2024-05-23. Score: 1
  
  **TLDR version:** A parser scans a linear string of symbols, presumed to belong to some language, and it applies the *grammar rules* of the language to discover the *structure* of information that is encoded by the string.
  
  > **Comments:**
  > **username_4**: How is that intelligible to someone to who it's unintelligible ?? [Sorry couldn't resist]  
  > **username_3**: @username_4, I guess I was looking back to a time in my own life when I would have understood words like "linear," and "grammar," and "structure," and "symbol;" but I had not ever heard of a software component called, "parser." I know some young people today who don't know the meanings of _any_ of those words. None of them has ever asked me what a parser does, and I don't expect that any of them ever will ask. If they do, I may have to politely decline.  
  > **username_4**: The thing is that a parser's 'symbols'  are very abstract -- they could be something called "IDENT" or "KEYWORD". This is unlikely to make sense to someone who doesnt understand the compiler toolchain  
  > **username_3**: @username_4, Well, I thought about that after I wrote my answer. I suppose that if I gave somebody my one sentence explanation (above,) and their eyes did not glaze over, and they asked for more; Then I might add that many parsers have a preliminary stage called "lexical analyzer," whose job is to group adjacent symbols into a linear stream of _tokens_ (a.k.a., "lexemes") and, to label each of them according to the role it plays in the grammar. I suppose I could go on from there until either (a) we have actually built a parser, or (b) their interest peters out.  
  > **username_4**: ... which is a "parser" in its own right!! Just that compiler writers dont usually call it that. From the computation theory pov a regular language is a context free language. And HecK! In the modern age the lexer may be preceded by a UTF8 "collector" which groups variable length UTF8 bytes into characters, which is an even more trivial lexer... therefore parser  
  > **username_4**: IMHO teaching this toolchain should be part of an introductory CS1 course. But that is not meaningful for "industrial languages" like Python Java what have you. It is not so hard for scheme say, where the parser is available directly as the library call `read`  
  > **username_3**: @username_4, IMO, what defines a _mere_ lexical analyzer is that it mostly just finds the beginnings and ends of tokens. Its input is a linear sequence of low-level symbols, and its output is _the same linear sequence,_ but grouped into larger, higher-level, labelled chunks with some limited decoding (e.g., its usually the lexer's job to compute the values of numeric literal tokens.) If a "parsing" function does anything more sophisticated than, say, decoding string literals that are allowed to contain escape sequences or, deciding what's octal and what's decimal; then IMO it's more than a "lexer."  
  > **username_4**: This is all compiler writer knowledge. And we return to the OP question. And my 1st comment .  The non smiley comment would be *Its a good question; And I don't have v good answers*.  But I can say I e written toy compilers in a dozen lines. Also lexers. By using a haskell like language  
  
  ---
  
  