Question on implementing "printers" in plugins

Hello.

I am working on prettier-java And do not fully understand the way printers are implemented.

The official docs say:

Printing is a recursive process of converting an AST node (represented by a path to that node) into a doc. The doc is constructed using the builder commands:

And I can inspect an example in the python plugin printer:

    case "Lambda": {
      return group(
        concat([
          "lambda",
          " ",
          path.call(print, "args"),
          ": ",
          path.call(print, "body")
        ])
      );
}

What I do not understand is why the “path” argument is needed. Assuming:

• I have a data structure representing the source code (in my case it is a CST - Concrete Syntax Tree) not an AST.
• I already have utilities to recursively traverse this data structure.

Could I simply traverse my CST and invoke the “builder” commands as needed? Without using the path for traversal?

In what cases would this path be required?

Cheers. Shahar.

[bd82]

How do you handle comments?

Toml

In Toml Comments are only allowed in specific points in the grammar. So they are explicitly parsed in the grammar instead of being collected or skipped by the Lexer.

• example of comments parsing

So handling of comments is just like handling any other grammar constructs.

• Printing of the rule with comments shown above

Prettier-Java

In prettier-java (which uses the same parsing library and data structures) it would be more complicated as comments are allowed everywhere in Java. So an additional step would be needed to attach the comments to the CST produced by the parser. and a more generic comment printing concept would be needed as comments could appear as part of any CST node.

[bd82]

Some of those capabilities sound useful and relevant, so I may need to find workarounds for those. Some of that functionality (comments/prettier-ignore) sounds like logical manipulation and analysis of string literals. So in theory it sounds like it does not have to be necessarily coupled to the FastPath and/or could be (re-)implemented as pure utilities.

Keep in mind, I don’t actually know what is going on under the hood and have still not implemented even a single prettier “printer” 😄 So I am likely not understanding the scenario / context completely.

I guess I will learn by doing and be wiser once I have actually written some prettier “printer” code I will be “wiser”.

You can either close this issue, or keep it open if you want me to post links and examples to my work here for farther discussion in the future.

Cheers.