Better indentation & layout for pretty-printing

[byorgey]

I kind of threw the pretty-printer together without much regard for how the layout and indentation works. The prettyprinter library has lots of nice tools for specifying this kind of thing; someone just needs to sit down and figure out how they work and how to apply them to the Swarm language to get good results.

This is very related to #7 , which will depend on this to get nice-looking save files that users can actually edit without tearing their hair out. Another semi-related issue is #644 .

At the moment, we use pretty-printing quite a bit for types, but we only pretty-print terms in certain error messages (e.g. when a command throws an exception).

[byorgey]

Some ideas for a nice pretty-printing style:

• Put consecutive lambdas on one line, then indent the body starting on the line beneath
• Put commands separated by ; on separate lines (with semicolons at end)

However, can we make the above somehow optional, so very short lambdas or very short command sequences just go on a single line? Some examples of the kind of thing I have in mind:

def id : a -> a = \x. x end

def repeat : int -> {cmd ()} -> cmd () =
  \n. \c.
    if (n == 0)
      { return () }
      { force c; 
        repeat (n-1) c
      }
end

[byorgey]

Some relevant things from the prettyprinter library:

• https://hackage.haskell.org/package/prettyprinter-1.7.1/docs/Prettyprinter.html#v:group
• https://hackage.haskell.org/package/prettyprinter-1.7.1/docs/Prettyprinter.html#v:flatAlt
• https://hackage.haskell.org/package/prettyprinter-1.7.1/docs/Prettyprinter.html#g:6
• https://hackage.haskell.org/package/prettyprinter-1.7.1/docs/Prettyprinter.html#v:punctuate

[xsebek]

Thanks for the resources @byorgey. If you plan to work on this please unassign me or I might just pick this up after 6 months. 😉

[byorgey]

OK! I wasn't necessarily planning to work on this. I just have a goal to "freshen" two github issues per day, which means picking the two least recently updated issues and improving them or moving them along in some (even small) way, like curating the tags, improving the title, adding a comment with additional thoughts or resources, etc. 😄

[xsebek]

I wonder what the rule should be for binds (;) I think it would be best to store whether the player explicitly used line break. Then we could collect those that were on the same line and lay them out using fillSep:

move; move; move; move;
turn right;
move; move; move; move;

+--------------------+
| move; move; move;  |
| move;              |
| turn right;        |
| move; move; move;  |
| move;              |
+--------------------+

[xsebek]

However, can we make the above somehow optional, so very short lambdas or very short command sequences just go on a single line?

@byorgey Yes, we can! group nicely turns newlines to spaces (or empty in case of line') so this is really nice and easy.

I played with it in 503f38b and got from this:

def forever = \c. c; force forever c end; def encircle = \lDir. \rDir. turn lDir; b <- blocked; if b {turn rDir} {wait 1}; fwBlocked <- blocked; if fwBlocked {turn rDir} {move} end; def patrolCW = force forever (force encircle right left) end; force patrolCW

to this:

def forever = \c. c; force forever c end;
def encircle =
\lDir. \rDir. turn lDir;
 b <- blocked;
 if b {turn rDir} {wait 1};
 fwBlocked <- blocked;
 if fwBlocked {turn rDir} {move}
end;
def patrolCW = force forever (force encircle right left) end;
force patrolCW

@byorgey any idea what will break with multiline pretty Term instance? 😅

---

As an aside, I think those force are wrong. The result does not type check again because e.g. forever does not have a delayed type. 😕 IMO we should either add the delayed braces or ideally not have force there.

[byorgey]

Re: force, see my comment here.