I actually discussed a solution like this with José in Prague but this will also become complicated very quickly, especially as these primivite nodes can be nested (e.g. keyword lists and normal lists). Maintaining the correct position in the parent is also problematic when you want to do something with the child nodes, for instance if you write an AST transform to swap 2 parameters of a function call, the comments would not get swapped.
For the short term I've put this subject to rest. My opinion is that for tooling that depends on code -> ast -> code transforms, we need more specialized tooling. For instance, we cannot assume that the input source code is already properly formatted; Ideally a source code modification tool should work with all kinds of source code, and a transformation should only affect the local scope, and not, for instance, reformat all of the output. I could even imagine it working with code that is not syntactically correct. That is a subject that the Elixir parser was just not meant to do, and trying to squeeze comments into the AST would not solve this. I have been looking at the Wrangler <https://github.com/RefactoringTools/Wrangler/> source code, which is a set of Erlang refactoring tools, but I have not come very far yet. It is an interesting source of information though. Arjan On Tuesday, April 23, 2019 at 12:18:07 PM UTC+2, [email protected] wrote: > > What about "hoisting" the comments into the metadata of the surrounding > block for the primitive AST nodes? > This means that we need to be able to specify *where* in a `:__block__` a > comment ought to occur, which shouldn't be a problem: The only cases where > this information will be out of date is when macro rewriting alters the > AST, which is a situation that would probably remove the comments anyway. > (so e.g. a formatter would need to move comments with the code just as is > the case currently, but optimization tools would not care about comments > anyway). > > This 'where' might take the format of a keyword-list, with > half-line-numbers as keys and strings (containing the actual comments) as > values. 'half-line-numbers ' go from 0 up to and including > `2*n_lines_in_block`. Even numbers are comments occuring before (e.g. on > the line above) `div(half-line-number, 2)`. Odd numbers are comments > occuring after (at the end of the same line as) `div(half-line-number/2)`. > > > So > > quote do > # one is the lonliest number > 1 > 2 # two is the smallest prime > 3 > # I am at the end > end > > > > would compile to > {:__block__, [comments: [0 => "one is the lonliest number", 3 => > "two is the smallest prime", 6 => "I am at the end"]], [1,2,3]} > > > ~Marten / Qqwy > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/df0438ce-45cb-4c90-b87c-c7a1ee9cc41b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
