Pretty printing fixes #476
Conversation
The T1, T2, etc. -style tuples are printed as if they are constructor applications, which have the same syntax as function application. Thus, they should have the same parentheses requirements as function application. Note that this was already correct for scalar tuples, only array tuples omitted the parentheses.
Previously, the parentheses requirements of Let and Alet were written as if they were function applications. However, this is untrue, since the body expression of a let-binding extends to the right as far as possible. This fixes the printer to _always_ add parentheses if there is a non-trivial expression context around the let-binding. We could be more conservative by allowing a context on the left only, but I thought this would be less surprising / more consistent.
Short answer is we don't. When I wrote the pretty printer I made a few different small test cases (things which didn't work well already, for example) and ran it through some larger programs as well, but it was all just done by eye. Nothing systematic like trying to round-trip the output. |
|
I guess it's not hugely important either, in particular since round-tripping isn't supported anyhow and thus if you want to evaluate the pretty-printed output you'll probably have to do some manual work anyway. I do have some ideas about how to implement a printer (even if non-pretty) that should be able to produce output that, when fed into Haskell again, should compile and be semantically equivalent modulo exact tuple layouts. If it so happens that I implement that at some point, we may want to test that. |
Description
Fixes for some of the issues in #470. (See also the commit descriptions.) I believe the
T1issue is strictly speaking not an issue, as I find it likely theT1just indicates a((), _)construction.Discussion point: How do we test pretty printing things?
I didn't fix the single-line let clause separation issue yet, because it's not as trivial as the two I did fix. I believe the do-notation example under
flatAltin the prettyprinter documentation could be adapted to our let-bindings, but I'm not fully certain, as the current implementation is quite different.Motivation and context
Syntactically unambiguous pretty-printing output is useful for a human reader, as well as if one tries to feed pretty-printed output back into Accelerate as Haskell code.
How has this been tested?
The examples in #470 have been tested.
Types of changes
What types of changes does your code introduce? Put an
xin all the boxes that apply:Checklist
Go over all the following points, and put an
xin all the boxes that apply. If you're unsure about any of these, don't hesitate to ask. We're here to help!