<p>I have been working on a standard for a simple stack based language for a few weeks now. It has an extremely simple syntax.</p>
<pre><code>&quot; world!&quot; &quot;Hello,&quot; + .
</code></pre>
<p>Outputs <code>Hello, world!</code>.<br />
For this language, would it make sense to create a parser, or should I just make a simple program that splits it up by spaces and executes it like that?</p>

<syntax><language-design><parsing><stack-based-languages>
Does a simple syntax stack based language need a parser?
CC BY-SA 4.0
2023-06-30T20:45:05.127Z
What is splitting up by spaces if not just very simple parsing?
RubenVerg
CC BY-SA 4.0
2023-06-30T20:46:27.807Z
@RubenVerg Because "parsing" implies creating an AST.
FlatAssembler
CC BY-SA 4.0
2023-06-30T20:48:44.677Z
and what is a list of strings if not a very simple AST?
RubenVerg
CC BY-SA 4.0
2023-06-30T20:52:03.677Z
@RubenVerg with that logic what is the output of a Lexer if not a simple AST?
poggingfish
CC BY-SA 4.0
2023-06-30T21:35:04.960Z
@RubenVerg The T in AST stands for "tree". A list of strings is not very tree-like.
Barmar
CC BY-SA 4.0
2023-06-30T21:54:11.583Z
Splitting on spaces will yield `"` and `world!"` as separate tokens. So that won't work.
kaya3
CC BY-SA 4.0
2023-07-01T05:39:38.307Z
@Barmar Lists are trees where each node has at most one child.
Abigail
CC BY-SA 4.0
2023-07-01T19:01:11.230Z
@Abigail I'm also not sure that a list of strings can be considered "abstract syntax" -- there are no syntactic types. So this list of strings is a really degenerate example of AST, with few of the qualities we generally consider applicable to them.
Barmar
<p>I implemented a &quot;simple&quot; stack-based language (Unix <code>dc</code>) using a stack-based interpreter. I basically had the exact perfect situation to avoid a parser.</p>
<p>I wrote a parser anyway. In fact I <em>also</em> wrote a lexer.</p>
<p>So I suggest you at least write a parser.</p>
<p>Here's why: your language will not have <em>just</em> stack operations; it will also have things like storing into variables (you don't know how much you want this until you don't have it), and if your language is Turing-complete, you also need a way to jump forwards and backwards.</p>
<p>Yes, you can implement this with stack operations (push a string and use that as the variable name, or do math on the current program counter location prior to a jump), but I think you will probably want an easier method eventually.</p>
<p>And when you do, I think you will be grateful for your parser.</p>

CC BY-SA 4.0
2023-06-30T20:59:51.570Z
2023-06-30T20:59:51.570Z
Gavin D. Howard
CC BY-SA 4.0
2023-07-01T06:49:01.020Z
I've done something very similar: an experimental notation that broke expressions up into a tree with lots of ad-hoc rules rather than an explicit parser... and regretted it. My conclusion was that if a notation isn't amenable to being handled by a simple and efficient parser, then there's something wrong with it.
Mark Morgan Lloyd
<p>For a language that has entirely trivial syntax, <strong>just splitting by spaces <em>is</em> a parser</strong>, and that’s fine. Concatenative languages with only number literals can be one case of that, for example.</p>
<p>It doesn’t look like your language is quite that, however: your example contains a space within the first quoted string! Splitting by spaces will break that apart, and while you can repair it, the work to do so and future-proofing would point me towards making a simple parser, personally. Here the parser really is essentially a lexer, but it will address keeping quoted strings as single terms, perhaps escapes, etc.</p>
<hr />
<p><strong>If you’re going to have even slightly more complex syntax</strong> — like quotes or function literals — <strong>you’ll probably need a real parser</strong>. Those are very common to enable things like conditionals; sometimes a “jump to last [“ suffices, but only in the very simple cases.</p>
<p>Any sort of structure or nesting brings that into play, so while for the very early stages of implementation you can probably get away without one, it’s likely you’ll have to make one eventually. If the language really is just a linear front-to-back model perhaps you escape that.</p>

CC BY-SA 4.0
2023-06-30T20:58:54.647Z
2023-06-30T20:58:54.647Z
Michael Homer
CC BY-SA 4.0
2023-06-30T21:32:58.390Z
Wouldn't this be more of a lexer than a real parser?
Barmar
CC BY-SA 4.0
2023-06-30T21:50:34.057Z
@Barmar Really, a lexer *is* a type of simple parser in the most general sense of the word “parser”. By convention, when a language uses a lexer, we use the word “parser” to refer to the secondary parsing step that comes after lexing. But if there is no such division of labor, the distinction isn’t very useful.
Alexis King
# Does a simple syntax stack based language need a parser?
Posted by: username_0 on 2023-06-30
I have been working on a standard for a simple stack based language for a few weeks now. It has an extremely simple syntax.
" world!" "Hello," + .

Outputs Hello, world!.
For this language, would it make sense to create a parser, or should I just make a simple program that splits it up by spaces and executes it like that?
**Tags:** syntax language-design parsing stack-based-languages
> **Comments:**
> **username_1**: What is splitting up by spaces if not just very simple parsing?  
> **username_2**: @RubenVerg Because "parsing" implies creating an AST.  
> **username_1**: and what is a list of strings if not a very simple AST?  
> **username_0**: @RubenVerg with that logic what is the output of a Lexer if not a simple AST?  
> **username_3**: @RubenVerg The T in AST stands for "tree". A list of strings is not very tree-like.  
> **username_4**: Splitting on spaces will yield `"` and `world!"` as separate tokens. So that won't work.  
> **username_5**: @Barmar Lists are trees where each node has at most one child.  
> **username_3**: @Abigail I'm also not sure that a list of strings can be considered "abstract syntax" -- there are no syntactic types. So this list of strings is a really degenerate example of AST, with few of the qualities we generally consider applicable to them.  
---
## 2 answers
### Answer by username_8 on 2023-06-30. Score: 10 | Accepted answer
For a language that has entirely trivial syntax, **just splitting by spaces *is* a parser**, and that’s fine. Concatenative languages with only number literals can be one case of that, for example.

It doesn’t look like your language is quite that, however: your example contains a space within the first quoted string! Splitting by spaces will break that apart, and while you can repair it, the work to do so and future-proofing would point me towards making a simple parser, personally. Here the parser really is essentially a lexer, but it will address keeping quoted strings as single terms, perhaps escapes, etc.

---

**If you’re going to have even slightly more complex syntax** — like quotes or function literals — **you’ll probably need a real parser**. Those are very common to enable things like conditionals; sometimes a “jump to last [“ suffices, but only in the very simple cases.

Any sort of structure or nesting brings that into play, so while for the very early stages of implementation you can probably get away without one, it’s likely you’ll have to make one eventually. If the language really is just a linear front-to-back model perhaps you escape that.
> **Comments:**
> **username_3** (2023-06-30): Wouldn't this be more of a lexer than a real parser?  
> **username_9** (2023-06-30): @Barmar Really, a lexer *is* a type of simple parser in the most general sense of the word “parser”. By convention, when a language uses a lexer, we use the word “parser” to refer to the secondary parsing step that comes after lexing. But if there is no such division of labor, the distinction isn’t very useful.  
---
### Answer by username_6 on 2023-06-30. Score: 5
I implemented a "simple" stack-based language (Unix `dc`) using a stack-based interpreter. I basically had the exact perfect situation to avoid a parser.

I wrote a parser anyway. In fact I *also* wrote a lexer.

So I suggest you at least write a parser.

Here's why: your language will not have *just* stack operations; it will also have things like storing into variables (you don't know how much you want this until you don't have it), and if your language is Turing-complete, you also need a way to jump forwards and backwards.

Yes, you can implement this with stack operations (push a string and use that as the variable name, or do math on the current program counter location prior to a jump), but I think you will probably want an easier method eventually.

And when you do, I think you will be grateful for your parser.
> **Comments:**
> **username_7** (2023-07-01): I've done something very similar: an experimental notation that broke expressions up into a tree with lots of ad-hoc rules rather than an explicit parser... and regretted it. My conclusion was that if a notation isn't amenable to being handled by a simple and efficient parser, then there's something wrong with it.  
---
