<p>What syntactic ambiguities can arise in a language with optional semicolons for statement or expression separators?</p>
<p>Let's say that that the syntax for this language generally follows the C syntax and that it is composed of:</p>
<ul>
<li>statements</li>
<li>expressions</li>
<li>keywords (that may or may not be reserved and be illegal identifiers) introducing special constructs like control flow constructs</li>
<li>curly braces delimited blocks when a syntactic construct allows for more than one statement or expressions (like function definitions, if/else if /else bodies, loop bodies, switch statement bodies, etc..)</li>
<li>generally non significant whitespace, whitespace would be only significant to delimit tokens. Statements and expressions could span several lines if need be.</li>
<li>function calls with potentially optional parentheses around their argument lists</li>
</ul>
<p>What syntactic ambiguities can arise in such a language with optional semicolons for statement or expression separators?</p>

<syntax><language-design>
What syntactic ambiguities can arise in a language with optional semicolons for statement or expression separators?
CC BY-SA 4.0
2023-07-27T17:09:05.837Z
This sounds like Ruby but with `{ ... }` instead of `do ... end`.
Bbrk24
CC BY-SA 4.0
2023-07-27T17:13:12.940Z
More like Perl except for the optional semicolons.
WhiteMist
CC BY-SA 4.0
2024-04-04T14:55:21.303Z
I would look at how Go handles this, imo it's much cleaner than what JS does. Essentially, in Go, if the last Token on a line COULD end a statement, a semicolon is automatically inserted. This avoids most of the footguns with JS, while letting you avoid writing semicolons most of the time.
CoffeeTableEspresso
<p>The hypothetical language you describe is quite similar to Javascript, in which semicolons are optional due to <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#automatic_semicolon_insertion" rel="noreferrer">automatic semicolon insertion</a> (ASI). There are well-known gotchas because of this, sometimes called ASI hazards.</p>
<h2>Function calls</h2>
<p>The following is either an expression followed by another expression in parentheses, or a function call where the expression <code>foo</code> is a function and the expression <code>bar</code> is its argument.</p>
<pre><code>foo
(bar)
</code></pre>
<h2>Indexed accesses</h2>
<p>The following is either an expression followed by a list literal with one element, or an indexed access expression.</p>
<pre><code>foo
[bar]
</code></pre>
<h2>Unary vs. binary operators</h2>
<p>The following is either an expression followed by a unary negation expression, or a single binary subtraction expression.</p>
<pre><code>foo
- bar
</code></pre>
<h2>Prefix keyword statements</h2>
<p>The following is either a bare <code>return</code> statement followed by an expression, or a <code>return</code> statement which returns the result of the expression.</p>
<pre><code>return
foo
</code></pre>

CC BY-SA 4.0
2023-07-27T17:14:43.720Z
2023-07-27T17:28:15.440Z
2023-07-27T17:28:15.440Z
kaya3
CC BY-SA 4.0
2023-07-27T17:16:46.670Z
Given the parentheses being optional in OP's description, `foo bar` would also fall under ambiguous function calls.
Jasmijn
CC BY-SA 4.0
2023-07-27T17:17:40.120Z
@Jasmijn Indeed, but either way it's either a function call or two expressions. I used parentheses because they're either required or optional for a function call.
kaya3
CC BY-SA 4.0
2023-08-01T02:31:52.317Z
Looks like all of these would be solved by requiring same indentation level for consecutive statements and deeper indentation level for multi-line statements.
Eldritch Conundrum
CC BY-SA 4.0
2023-08-01T10:26:37.157Z
@EldritchConundrum There are various ways to remedy these ambiguities, the most obvious one being to require semicolons. I'm not aware of any languages with the rule you describe (though please mention them if there are any), and such a rule would forbid e.g. placing a closing bracket at the end of a multi-line expression at the start of the next line, which is a very common style.
kaya3
CC BY-SA 4.0
2023-08-01T17:17:15.580Z
I didn't have a language in mind, but in the meantime I found this one: https://langdev.stackexchange.com/a/451/875 . The closing bracket has to be indented, that seems good to me.
Eldritch Conundrum
CC BY-SA 4.0
2023-08-13T05:46:14.440Z
Another one is "foo\nbar" (foo on the first line, bar on the second line). It can be either interpreted as `foo(); bar();` or as `foo(bar());`. There are also other ambigiuties due to the optional parentheses around the parameter list of the function call. "foo" 's type could be variable or a function, and independently of that we don't know if it's a function call or not.
WhiteMist
# What syntactic ambiguities can arise in a language with optional semicolons for statement or expression separators?
Posted by: username_0 on 2023-07-27
What syntactic ambiguities can arise in a language with optional semicolons for statement or expression separators?

Let's say that that the syntax for this language generally follows the C syntax and that it is composed of:

* statements
* expressions
* keywords (that may or may not be reserved and be illegal identifiers) introducing special constructs like control flow constructs
* curly braces delimited blocks when a syntactic construct allows for more than one statement or expressions (like function definitions, if/else if /else bodies, loop bodies, switch statement bodies, etc..)
* generally non significant whitespace, whitespace would be only significant to delimit tokens. Statements and expressions could span several lines if need be.
* function calls with potentially optional parentheses around their argument lists

What syntactic ambiguities can arise in such a language with optional semicolons for statement or expression separators?
**Tags:** syntax language-design
> **Comments:**
> **username_1**: This sounds like Ruby but with `{ ... }` instead of `do ... end`.  
> **username_0**: More like Perl except for the optional semicolons.  
> **username_2**: I would look at how Go handles this, imo it's much cleaner than what JS does. Essentially, in Go, if the last Token on a line COULD end a statement, a semicolon is automatically inserted. This avoids most of the footguns with JS, while letting you avoid writing semicolons most of the time.  
---
## 1 answers
### Answer by username_3 on 2023-07-27. Score: 6 | Accepted answer
The hypothetical language you describe is quite similar to Javascript, in which semicolons are optional due to automatic semicolon insertion (ASI). There are well-known gotchas because of this, sometimes called ASI hazards.
Function calls
The following is either an expression followed by another expression in parentheses, or a function call where the expression foo is a function and the expression bar is its argument.
foo
(bar)

Indexed accesses
The following is either an expression followed by a list literal with one element, or an indexed access expression.
foo
[bar]

Unary vs. binary operators
The following is either an expression followed by a unary negation expression, or a single binary subtraction expression.
foo
- bar

Prefix keyword statements
The following is either a bare return statement followed by an expression, or a return statement which returns the result of the expression.
return
foo
> **Comments:**
> **username_4** (2023-07-27): Given the parentheses being optional in OP's description, `foo bar` would also fall under ambiguous function calls.  
> **username_3** (2023-07-27): @Jasmijn Indeed, but either way it's either a function call or two expressions. I used parentheses because they're either required or optional for a function call.  
> **username_5** (2023-08-01): Looks like all of these would be solved by requiring same indentation level for consecutive statements and deeper indentation level for multi-line statements.  
> **username_3** (2023-08-01): @EldritchConundrum There are various ways to remedy these ambiguities, the most obvious one being to require semicolons. I'm not aware of any languages with the rule you describe (though please mention them if there are any), and such a rule would forbid e.g. placing a closing bracket at the end of a multi-line expression at the start of the next line, which is a very common style.  
> **username_5** (2023-08-01): I didn't have a language in mind, but in the meantime I found this one: https://langdev.stackexchange.com/a/451/875 . The closing bracket has to be indented, that seems good to me.  
> **username_0** (2023-08-13): Another one is "foo\nbar" (foo on the first line, bar on the second line). It can be either interpreted as `foo(); bar();` or as `foo(bar());`. There are also other ambigiuties due to the optional parentheses around the parameter list of the function call. "foo" 's type could be variable or a function, and independently of that we don't know if it's a function call or not.  
---
