Multi line chained operator syntax

[JaroslavTulach]

Pull Request Description

Fixes #7904.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Java,
  style guides.
• All code has been tested:
  • Unit tests have been written where possible.

[JaroslavTulach]

@kazcw, is there a documentation or tests of the chained operator syntax other than this single paragraph?

What happens when the operator isn't ., but something else? Is it an error (just like in my PR)?

[somebody1234]

there seem to be more tests here:

enso/lib/rust/parser/debug/tests/parse.rs

Lines 458 to 481 in 5216b8c

	#[test]
	fn code_block_operator() {
	let code = ["value = nums", " * each random", " + constant"];
	let expect = block![
	(Assignment (Ident value) "="
	(OperatorBlockApplication (Ident nums)
	#(((Ok "*") (App (Ident each) (Ident random)))
	((Ok "+") (Ident constant)))
	#()))
	];
	test(&code.join("\n"), expect);
	}
	#[test]
	fn dot_operator_blocks() {
	let code = ["rect1", " . width = 7", " . center", " + x"];
	#[rustfmt::skip]
	let expected = block![
	(OperatorBlockApplication (Ident rect1)
	#(((Ok ".") (OprApp (Ident width) (Ok "=") (Number () "7" ())))
	((Ok ".") (OperatorBlockApplication (Ident center)
	#(((Ok "+") (Ident x))) #()))) #())];
	test(&code.join("\n"), expected);
	}

the first case contains other operators:

value = nums
    * each random
    + constant

the second case contains a nested OperatorBlockApplication:

rect1
    . width = 7
    . center
        + x

note that as per the design, it should be semantically equivalent to (((rect1) . width = 7) . center + x)

but at the very least, it means that the parser supports both these cases - i guess it's not explicitly part of the design, however the design does always say "an operator" rather than "the dot operator"

[JaroslavTulach]

According to @somebody1234's comment this is the desired behavior.

[JaroslavTulach]

@somebody1234, @kazcw I am not sure what to think about

the second case contains a nested OperatorBlockApplication:

rect1
    . width = 7
    . center
        + x

note that as per the design, it should be semantically equivalent to (((rect1) . width = 7) . center + x)

I believe it is not a valid syntax: what should it mean rect1.width = 7? Assignment to a field width? There are no assignments to fields in Enso.

[somebody1234]

@JaroslavTulach yeah... i'd assume that one is just a parser test. ((rect1) . width = 7).center makes even less sense, i think

[JaroslavTulach]

The other inquiry I have is with nested blocks

rect1
    . width
    . center
        + x

what's the difference between the above and no-nesting block?

rect1
     . width
     . center
     + x

the latter one is clearly ((rect1 . width) . center) + x according to the short spec, but the first one? Does it have the same meaning (why do we have double syntax meaning the same)? Or should it first evaluate the nested block - e.g. (center + x).

[JaroslavTulach]

The behavior probably isn't fully correct, but the specification is so fuzzy that it's not clear what is correct anyway. Let's integrate at current state and solve the rest as bugs.