Thanks for looking at this, Roman.
FYI, that's not the grammar I'm working from - that's more of a sketch of a grammar, for humans to read when PowerShell was new, but not to write a parser from. There's a lot missing, and a lot of errors.
There is an official grammar in the PowerShell Language Specification ( http://www.microsoft.com/en_us/download/details.aspx?id=9706). It's much more complete, although I'm discovering a few errors as I go. I guess I'm the first one to ever use it.
From the spec, section 2.2.4:
Unlike some popular languages, PowerShell does not consider line-terminator characters (§2.2.2) to be white space. However, a line terminator can be treated as white space by preceding it immediately by a backtick character,
` (U+0060). This is necessary when the contents of a line are complete syntactically, yet the following line contains tokens intended to be associated with the previous line.
The "syntactically complete" bit is important. For example:
PS> if ($false) # this if includes the block
Here, the grammar for `if` requires a block to follow, so the parser will continue looking on the next line for that block. Since the open brace requires a close brace, the parser will taking input until it gets that close brace. At
that point it will evaluate the entire input. Because the condition is false, the block won't run, and no output will appear. This is all one statement.
PS> Set-Item function:prompt # this command does not include the block
>> "PS> "
In this case, the first `Set-Item` command will accept a block as a parameter, but the parser doesn't know that. Instead, the grammar says a command ends with a newline. It processes the `Set-Item` command when you hit ENTER. Then it sees the open
brace and starts parsing again. When you're done, the block is executed, and produces an output. This is all 2 statements.