[Grace-core] Layout rules for Grace

[Andrew P. Black]

Herewith is a first cut at layout rules for Grace.  

Some background: We agreed last winter in London that we would require { and } instead of trying to infer them from indentation, but that indentation would be required so that programs were readable, and so that all programs have the same appearance.  This is to avoid a student who has learned Grace form one book being confused when she looks at a web page with different formatting. 

We also agreed to enforce this by having the compiler reject programs where the indentation was wrong.  However, we never wrote down the rules.  This is notoriously difficult.  I'm sure that what follows isn't right, but I think that it is a reasonable first cut.  As we apply these rules to Grace code, we will find examples where they don't work, and then — and only then — we will embellish the rules.

I hope that what is here will be sufficient to print out a Grace program from an AST.

• The } that closes a block must be either
	(1) on the same line as the corresponding }, or
	(2) at the same indentation level as the start of the line that contains the opening {

If { and } are not on the same line, then there must be a newline after the {, and all of the intervening lines must
be indented at least 3 spaces more than the start of the line that contains the opening {

Example:

   type { x:Number; y: Number }

or

   object {
      method … {…}
      method … {…}
   } 

• A multi-part method name shall be written either
	(1) all on one line, or
	(2) with all parts of the name at the same indentation.

Example:  

   while { … } do {…}  

or

   while {…}
   do {…}    

• The maximum line length is under the control of the user.  (It is not pre-defined to be 80!).  This is so that we can use the pretty-printer to fill a slide, a book page, or an editor window.

• A continuation line must be indented 3 (or more) spaces more than the line that it is extending.  There is no implied semicolon before a continuation line.

• The rule for { and } above also applies to ( and ). However, a multi-line (...) expression will be much less common than a multi-line {...}

• A comment shall be printed immediately following the syntactic unit to which it refers, either on the same line (if it fits), or on succeeding lines at the same indentation level as the unit to which it refers. 

• The = in a def shall have a space on either side
	Example:  	   def maxSpeed = 85

• The := in an assignment shall have a space on either side.
	Example:     speed := 55

• The : that introduces a type annotation shall not have spaces before or after
	Example:     speed:aNumber