3
$\begingroup$

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?

$\endgroup$
3
  • $\begingroup$ This sounds like Ruby but with { ... } instead of do ... end. $\endgroup$
    – Bbrk24
    Commented Jul 27, 2023 at 17:09
  • $\begingroup$ More like Perl except for the optional semicolons. $\endgroup$
    – WhiteMist
    Commented Jul 27, 2023 at 17:13
  • $\begingroup$ 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. $\endgroup$ Commented Apr 4 at 14:55

1 Answer 1

6
$\begingroup$

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
$\endgroup$
6
  • 1
    $\begingroup$ Given the parentheses being optional in OP's description, foo bar would also fall under ambiguous function calls. $\endgroup$
    – Jasmijn
    Commented Jul 27, 2023 at 17:16
  • $\begingroup$ @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. $\endgroup$
    – kaya3
    Commented Jul 27, 2023 at 17:17
  • $\begingroup$ Looks like all of these would be solved by requiring same indentation level for consecutive statements and deeper indentation level for multi-line statements. $\endgroup$ Commented Aug 1, 2023 at 2:31
  • $\begingroup$ @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. $\endgroup$
    – kaya3
    Commented Aug 1, 2023 at 10:26
  • $\begingroup$ I didn't have a language in mind, but in the meantime I found this one: langdev.stackexchange.com/a/451/875 . The closing bracket has to be indented, that seems good to me. $\endgroup$ Commented Aug 1, 2023 at 17:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .