[Grace-core] Indentation (After Teleconference)

[Andrew P Black]

We discussed this on Monday 16th February 2015

On 16 Feb 2015, at 14:47 , Andrew P Black <black at cs.pdx.edu> wrote:

> Indentation Questions
> 
> Q0  Do we care where closing braces go?
> 
> Do they always have to align with the indentation of the line that opened the brace, or do we allow them anywhere?

Our conclusion

	If a closing brace is on a line by itself, then it must be at the same indentation as the line that opened the braced-construct.
	However, if a brace is on a line with other stuff, then it can fall anywhere.
> 
> Q1 Indentation of continuation lines
> 
> Suppose we have a continuation line:
> 
>          (X + y).
>                   foo {
> 
> where does the next line (the body of the block) go?  It has to be indented, because of the '{', but to the right of what?   The '(' on line 1 (because it's the indentation of the logical line that the block contents has to be to the right of)?   Or the 'f' on line 2 (because thats the line where the block opened?
> 
> Does the first rule make 
> 
>          (X + yVeryLong).
>                   foo {
>                   if (b) then {
>                            ...
>                   } else {
>                            ...
>                   }
> 
> legal?  I think that the above is visually confusing.  Do we want the student to write
> 
>          (X + yVeryLong).
>                            foo {
>                   if (b) then {
>                            ...
>                   } else {
>                            ...
>                   }
> 
> or
> 
> 
>          (X + yVeryLong).
>                   foo {
>                            if (b) then {
>                                     ...
>                            } else {
>                            ...
>                            }
> 
> ?

Answer: We prefer the second form, since it distinguishes the "continuation line indent" from the "new block indent".   The proposed rule is:
When a line is been continued with one or more indented continuation lines,  the indentation of all of the continuations must be the same, and the indentation of the first line that is NOT part of the continuation must be less.

Let me try to be more precise:

	When a line L(a) has indentation n, and the following line L(a+1) also has indentation n,  then the two lines are treated as separate statements or declarations, if that is syntactically legal.  If L(a+1) has indentation m > n+1, then L(a+1) is treated as a continuation of the statement or declaration on  L(a).   If subsequent lines  L(a+2),  L(a+3), … have indentation m, then they also continue the statement or declaration started on the first line.  

	The next line  L(a+k) with an indentation p ≠ m ends the sequences of continuation lines.  It's a syntax error for p > m.  Hence, p < m.  In the common case, p = n, which signals the next statement or declaration following that on L(a).  It's also possible for p < n, which must coincide with the end of a braced-construct started prior to  L(a), or for n < p < m, which coincides with the start of a braced construct that started on the last continuation line.

Ugh!  Anyone else want to try?   I feel that we need non-teminals in the syntax that mean "statement or declaration" and "braced construct".
Note that the m > n+1 is deliberate.  Indentation changes must be made in units of 2 or more — a change of 1 is always an error, because it is so small visually that it might be a typo, or it might be a deliberate change.

> Q2.  Can a block have expressions on the opening line.
> 
> For example, in
> 
>          requestName { thing1
>                   thing2
>                   thing3
>          }
> 
> is thing1 permitted?  If so, so thing2 and thing3 have to be verticlally below thing1, or is it ok to allow them to be as shown above?
> 

Conclusion:  This formatting is not permitted.  This is because it's ambiguous whether the first request is thing1thing2 (because of the implied continuation line), or thing1 (where the indentation is there because of the new block.)  So we should write either

         requestName {
		  thing1
                  thing2
                  thing3
         }

or
         requestName { thing1 ;  thing2 ;  thing3 }

or

         requestName {
		  thing1thing2
                  thing3
         }

or
         requestName { thing1thing2 ;  thing3 }

depending what we mean.

	Andrew


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20150216/3941bc90/attachment-0001.html>