ast-types
ast-types copied to clipboard
benjamn
Question: Why are Comment nodes treated differently than any other node
Hey there @benjamn, I have a question, I'll try to keep myself short.
Comment nodes are contained within the comments member of a block node, whereas most other nodes live inside the body member of a block node.
I'm working on a project that uses the ast-types library and recast to turn a coffee-script AST into an es6 AST and although it's going well, comments are a stumbling block because they behave differently than any other node. As far as I'm aware the recast printer needs line/column coordinates to be able to print comments.
I'm sure there's a good reason for this. Would you mind explaining it to me?
Also, do you have an idea of how you'd go about solving this problem?
i guess the simple solution is that they aren’t part of the semantic structure:
e.g. a binary expression contains left hand side operand right hand side and any number of comments at any point in between.
i guess i’d have done it by attaching the comment nodes to the node before/after instead of the block, so that locality would have been maintained even when transforming the tree.
but maybe there’s a good reason for not doing that.
and yeah, it’d be awesome to have an easy way to insert comments into a synthesized tree. (i.e. passing block, preceding node, some local whitespace info, and comment text to a function which will figure out how to set the location)
@flying-sheep very plausible. Attaching comments to a node would be awesome.
Comments are special/hard because their relationship to the nodes they annotate is so hard to infer. That's partly because they can appear anywhere, even in places where no real node could appear, so it can be very difficult to attach them to the AST in a way that accurately expresses their positioning: leading, trailing, dangling, dangling between two commas in an array literal with holes, trailing but vertically aligned with comments on lines above and below, etc etc. Is a comment at the beginning of a file a file comment, or a comment about the first body element? There are no good answers, only rough heuristics, so Recast optimizes for the common case where you just want to move all the .comments from one node to a new node (though sometimes it is tricky to know which node the comments were originally associated with).
Some important invariants: a comment can only belong to a node if it falls somewhere within the .loc of the node's parent node, and Recast prefers leading/trailing comments to dangling comments at all costs, because it's so hard to know where to print a dangling comment.
It would definitely make life easier in some cases if comment nodes could appear in place of syntax nodes: for example, it's really hard to represent a single comment in an otherwise empty function parameter list without actually pushing the comment onto the parameter list. Recast can handle that sort of AST abuse just fine, but the resulting AST definitely isn't valid according to any spec.
In short, I'm open to pull requests that improve comment handling, but I must also warn you: here be dragons.
thanks for the explanations!
do you know something that helps with our inserting comments problem?
Some further explanation: https://github.com/benjamn/recast/issues/159#issuecomment-76054246
