Jose, Thought that you were mentioning that metadata could be added to those that don't have metadata? You're prior comments made it sound like it could be worked around (potentially) and that you would be supportive of that. Did I miss understand you?
>From you're prior reply: > I like the metadata idea a lot, thanks. We still need someone to send a > detailed proposal, including what will happen with inline comments, > comments inside blocks and comments as the last line of a block with no > expression afterwards. > > We also need a discussion on what will happen with nodes that do not have > a metadata entry. Wrapping those in a block is likely enough (but it will > break semantics, for example, in keywords lists). So it would need to be an > opt-in feature only. On Tue, Apr 16, 2019 at 2:00 PM José Valim <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KWbudLS31NPDcuCVaM4y3DZj58%2BHftj8YJnobQJ4MmWg%40mail.gmail.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/CAPxhEGf%3DFmRMxGqb8QDMNSFT56nuP2%2BeiVgVcKnmLL5ob5g%3Dsw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
