Note for printing purposes you will want to filter out:

• TokLayoutStart
• TokLayoutSep
• TokLayoutEnd
• TokEof

I do need to print the comments on TokEof though, if I don't want to lose trailing comments, right?

Oh, that's right. The reason is that the provided token printer will print <eof> literally, which we use in the layout golden tests. You might need to add some customization to the printer.

Allright, this seems to work on all the test files (apart from some unicode nonsense with Haskell on Windows in GHCI)

Anything in particular you'd like me to test here? I could check round tripping for all the layout tests.

The layout tests don't necessarily parse to a module, they only test the lexer.

I feel like testing all passing source files is a little much, but maybe it's fast enough that it doesn't matter.

Allright.... there's no good test body in purescript-cst I could use then. I guess we could start adding to it whenever we find an issue where it doesn't roundtrip.

Oh right, it's a separate module. I guess we could try it. If they all parse as a module, then that seems fine to me.

FWIW all of tests/purs/passing roundtrips.

After putting the following script into Script.hs in the project root it can be run with stack runhaskell Script.hs:

{-# language BlockArguments #-}
import Prelude
import Data.Foldable
import Language.PureScript.CST.Types as CST
import Language.PureScript.CST.Parser as CST
import Language.PureScript.CST.Print as CST
import Data.Text (Text)
import Data.Text.IO as Text
import System.Directory
import System.FilePath

readModule :: FilePath -> IO (Text, CST.Module ())
readModule path = do
  contents <- Text.readFile path
  let module_ = either (error . show) id (snd (CST.parse contents))
  pure (contents, module_)

main :: IO ()
main = do
  go "tests/purs/passing"
  where
    go :: FilePath -> IO ()
    go dir = do
      listDirectory dir >>= traverse_ \path ->
        if isExtensionOf "purs" path then do
          print path
          (content, module_) <- readModule (dir </> path)
          if content == CST.printModule module_ then pure () else error path
        else if isExtensionOf "js" path then pure ()
        else go (dir </> path)

@joneshf Now that we have the purescript-cst library, how would I go about making a minor release of it that includes this change?

I'm sorry, I don't really understand the question. Could you rephrase it?

The point of coming up with the separate version scheme for the sub-packages like purescript-cst was so we could release changes and improvements to them without having to make a compiler release.

Now I'm wondering how to actually make that happen, because I'd like to use this change in an experiment of mine that doesn't depend on the whole compiler, but it doesn't seem like purescript-cst is published to Hackage.

I'm asking you because I remember you lobbying strongly for it. If you don't know what the process is, no worries.

We could make an initial release of purescript-cst now. We don't really have a procedure for that yet, since this would be the first one. Actually uploading to Hackage is pretty straightforward: I think it should just be cd lib/purescript-cst && stack upload .. We should probably also add a tag to this repository so that it's easy to identify which commit corresponds to which version, perhaps purescript-cst-0.1.0.0?

The only potential awkwardness is that this release would include syntax for kind signatures and role declarations, but those don't yet exist in any released compiler version. I'm not sure that's necessarily such a problem that we should wait until 0.14.0 is out, though.

Oh also, if you upload a release, could you please add the rest of us as maintainers? By default only the initial uploader will be permitted to upload subsequent versions.

We should probably add instructions to the RELEASE_GUIDE.md file for making releases of the purescript-ast and purescript-cst libraries at some point, too.

This is awesome! I was just going to ask about this in fp-chat if there was any plan to separate purescript-cst and purescript-ast but didn't wanna bother yall for some dumb personal project I have, but I imagine this will probably be great for people who want to build tooling around purescript projects.

The point of coming up with the separate version scheme for the sub-packages like purescript-cst was so we could release changes and improvements to them without having to make a compiler release.

Now I'm wondering how to actually make that happen, because I'd like to use this change in an experiment of mine that doesn't depend on the whole compiler, but it doesn't seem like purescript-cst is published to Hackage.

Got it, thanks for rephrasing! I would go with what @hdgarrood's laid out.

I'm asking you because I remember you lobbying strongly for it. If you don't know what the process is, no worries.

Nah, I'm pretty much indifferent to what the versioning scheme is. My only preference is that whatever the scheme is, it fosters iteration. We can change it to whatever works, for all that I care.