Parse expression should never return a sequence node

[guillep]

Describe the bug

RBParser >> parseExpression: could return a sequence node.

To Reproduce

RBParser parseExpression: '
  1+2.
  2+3.'

Expected behavior
An error

Version information:
Pharo 9.0.0
Build information: Pharo-9.0.0+build.634.sha.658326a3eb4f26b45dc0efe988aa945d5470876b (64 Bit)

[MarcusDenker]

I think this is because for a "Doit" or "PrintIt" you actually can select multiple lines (more than an expression).

This is parsed with parseExpression:,

I guess this is why the ST80 Compiler used "parse without method pattern" as a terminology... (see #noPattern:)

[privat]

Not sure if it's a bug. Bad terminology at most.

"Expression" seems to be user rather broadly in Pharo as any piece of code you might execute or expect a value. This could be a contamination from languages where sequences of expressions are also expressions.
What was the context where you wanted a real expression and not a sequence (if you remember)?

To add to the confusion, the parser also offers a parseDoIt that injects a synthetic return node at the last statement.
parseDoIt seems to be the one used for DoIt or PrintIt and for OpalCompiler#>>evaluate:

The terminology "noPattern" is so much bad that it might underflow.

Calypso, Rubric and Spec2-Code seems to use the terminology isScripting (only in a boolean form?). That is not that bad.
But I'm not sure if it is worth the hassle to rename for the sake of renaming, but it could be an opportunity in case there is an unrelated API change.

[hernanmd]

I get a "RBSequenceNode(1 + 2. 2 + 3)"

So this could be closed (or renamed)?