Hi Steve, as mentioned in this discussion, we can't really store it in the AST as not all nodes have metadata. My suggestion is to keep it on the side, similar to how we do in the formatter. Thanks for offering the bounty though!
*José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Tue, Apr 16, 2019 at 10:10 PM Steve Morin <[email protected]> wrote: > Jose, RE adding comments to AST meta data. Realized I don’t have time to > add it. But what are your feeling on me putting up a bounty on it? > > On Apr 16, 2019, at 12:02, José Valim <[email protected]> > wrote: > > I have to disagree on some points: > > 1. Traversing the AST is not as complex as it sounds. You literally need > four clauses (and the first two can be written as proxy to the third): > > def traverse({left, meta, right}) > > def traverse({one, two}) > def traverse([_ | _] = list) > > def traverse(other) > > > 2. If we converted everything to 3 element tuples, the issue is not only > Macro.keywordify as there are also macros that match on atoms too (and on > strings too albeit less common). For instance, every Phoenix application > does it . So making everything a three-element tuple would hurt that. > > 3. Note that {:integer, [], 1} and {:atom, [], "foo"} would be their own > AST nodes too, as there are now new rules for what the 3 element actually > is. Sure, it is more consistent in terms of metadata, but you are not > really reducing the number of nodes. You could make them {:integer, meta, > [1]} and similar but that would mean introducing new special forms. > > I definitely agree that having a fixed place for metadata would improve > certain cases but the trade-offs are much more nuanced than implied. The > current AST was not optimized for reconstruction but for developer > ergonomics and I believe the proposed standardisation would make certain > features much more bureaucratic. > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > > -- > 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/CAGnRm4JDiCU2-viWn06FOwLAQKTZ-ufTPdihUn8UnaTcC5ZHfw%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JDiCU2-viWn06FOwLAQKTZ-ufTPdihUn8UnaTcC5ZHfw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- > 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/D78F2CE6-1EA1-4C16-8EDE-37FBD7005ED7%40gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/D78F2CE6-1EA1-4C16-8EDE-37FBD7005ED7%40gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAGnRm4KWbudLS31NPDcuCVaM4y3DZj58%2BHftj8YJnobQJ4MmWg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
