Closed kjx closed 3 years ago
I don't think so.
We have to decide if the increase in indentation on line 2 is to indicate a continuation line, or because a block has started. Because line 1 has an unmatched {
, line 2 starts a block, and the indentation is assumed to be that required by starting a block.
If instead you write
valueOf { print(1)
print(2)
print(3) }
then you get Syntax error: Please indent the body of a block
.
In hindsight, it may have been a mistake to use indentation for these two disparate purposes. But the escaped newline convention used by Python (and shell) is so ugly ...
Yeah escaped newlines are surely evil.
Given that indentation of print(1)
starts at col 11,
I don't see why when it comes to the indentation of print(2)
:
that's to say the required indentation inside a code sequence is the indentation of the start of the first statement in the code sequence, where than needs to be to the right of the previous indentation.
Given that indentation of print(1) starts at col 11,
Grace is not Haskell. We count not the indentation of a statement; rather we count the indentation of the line that contains the statement. Hence, thou shalt say
the indentation of the line containing `print(1)` is zero
It shalt also also be seen that the line containing print(1)
openenth a block, as the {
bears withness thereto
Hence, until the closing }
It is not possible to both start a block on the current line, that is, to put a statement after an unmatched opening {
, and to continue that statement on the next line. If the statement won't all fit to the right of the {
, start a new line after the {
Grace is not Haskell
Which is why most of the Haskell-inspired work on indentation inference and specification was not much help to us.
prints
shouldn't it complain about a missing
print(_)print(_)print(_)
method?