dhall-format removes comments

[psibi]

Example file:

--- This is dhall file
{ foo = "jax" }

The Output it gives:

{ foo = "jax" }

[psibi]

Going through the code, it seems a known issue. :) Anyway keeping this open.

[Gabriella439]

One thing I can do as an immediate workaround is to have the formatter preserve leading whitespace and comments at the beginning of the file. Then if you need comments for a subexpression you can at least have the workaround of splitting it out into another file

[f-f]

@Gabriel439 What's the main challenge to tackle in order to fix this? As far as I remember the main problem is that it'd be hard to associate comment fragments to other AST nodes, right? (as in: a comment line that comes before some code goes with the next node, but what to do in case of a comment fragment on the same line? Also how about the alignments? And does this mean that comments would slow down all operations, since it's a whole lot of packing-unpacking dummy AST comment nodes?)

[ocharles]

The GHC approach is not to out comments in the AST, but have a separate map Map (NodeType, SrcLoc) Annotation. So as you traverse the AST you have SrcLocs and can find annotations for the node you're at. That's one approach. Or we could have a trees that grow approach and erase comments from the AST for anything but formatting.

…

On Thu, 1 Nov 2018, 9:53 am Fabrizio Ferrai ***@***.*** wrote: @Gabriel439 <https://github.com/Gabriel439> What's the main challenge to tackle in order to fix this? As far as I remember the main problem is that it'd be hard to associate comment fragments to other AST nodes, right? (as in: a comment line that comes before some code goes with the next node, but what to do in case of a comment fragment on the same line? Also how about the alignments? And does this mean that comments would slow down all operations, since it's a whole lot of packing-unpacking dummy AST comment nodes?) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#145 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABRjlJH8aGjbXdkKSoOcAC8gEWfHHQ6ks5uqsSsgaJpZM4PoYNA> .

[Gabriella439]

There is also a third solution, which is a "low-tech" formatter that doesn't actually parse the AST but rather just scans the text and formats as it goes. I believe this is how go fmt works.

However, I think the simplest and most robust solution is the second one that @ocharles mentioned which is just to preserve parsed whitespace in the syntax tree using the Noted constructors.

That still doesn't get us all the way, though, because intelligently preserving comments when formatting code is still difficult even when your AST preserves whitespace and comments. Here are some pathological cases to consider when designing a comment-preserving formatting algorithm:

• The formatter wants to format an expression as one line since it's less than 80 characters, but there is a line comment in the way:

  { x = 1  -- !
  , y = 2
  }

• Same as the previous example, but now there is a multi-line comment in the way:

  { x = 1  {- !
              !
           -}
  , y = 2
  }

• The formatter wants to reindent a value but doing so might break the indentation of a multi-line comment:

  [ 1
  , 2
  ...
  ,     99 {- !
              !
           -}
  ]

• Same as the previous example, except that te user wrote the multi-line comment using multiple single-line comments (i.e. -- ), so the formatter doesn't know that they are supposed to be indented together:

  [ 1
  , 2
  ...
  ,     99 -- !
           -- !
  ]

• User inserts comments preceding syntactic elements that we want to horizontally align:

  [ 1
  , 2
  ...
  {- ! -} , 99
  ]

• User adds a comment that goes beyond the desired column limit:

  1 -- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

• User adds whitespace before a comment pushing it beyond the desired column limit:

  1                                                                                          -- !

[macalinao]

I'd like to have comments on record fields if possible. This doesn't work right now.

let Block
	: Type
	= { id :
		  Text
		  -- Used in radio selects, checkbox selects
	  , label :
		  Text
	  , fieldType :
		  Text
	  , options :
		  List { id : Text, label : Text }
	  }

gets nuked.