Arjan Scherpenisse What is you're use-case? On Tue, Apr 23, 2019 at 4:20 AM Arjan Scherpenisse <[email protected]> wrote:
> 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 > <https://groups.google.com/d/msgid/elixir-lang-core/df0438ce-45cb-4c90-b87c-c7a1ee9cc41b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Steve Morin | Hacker, Entrepreneur, Startup Advisor twitter.com/SteveMorin | stevemorin.com *Live the dream start a startup. Make the world ... a better place.* -- 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/CAPxhEGfCWE5FdzdrnffdFMP6UPc0mReKOEsK6TLSYEZ644Xe%2Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
