`-dparsed` produces invalid BSV module function that takes another module as an argument about bsc HOT 2 OPEN

Thanks for reporting these. There's been no effort to make sure that the pretty-printer for an entire BSV file will read back in correctly and identically, so I am not surprised if you find issues like this. The only concern was the printing of any snippets that appear in error messages to the user, which are usually just types, or IDs, or individual method calls. The -d dump flags were considered hidden features for developers, and they didn't need to be perfect (and could change or disappear at any time). But it's a good aim to have the pretty-printer work for full programs, so thank you for reporting this.

The module type should be preserved. I assume that this is just a bug in CVPrint.hs, probably around line 165, in the function p2defs:

line1 = t"module" <+> pvpId d i <> f ys <> t"(" <> pvPrint d 0 ity <> t")"

from bsc.

Thanks! And I certainly don't expect the pretty-printer to be 100% accurate in all cases. My use case is that I am generating very simple BSV code programmatically using the bsc source code, and I ran into some situations where even very simple code fails to parse when fed back into bsc. My goal is to fix only those issues that I encounter when pretty-printing the very limited subset of BSV that I'm generating.

I'll give CVPrint a closer look. For posterity's sake, here is a permalink to the code mentioned in #663 (comment):

from bsc.