--
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 elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/955237D8-31DE-448C-9777-1104F1175DC7%40gmail.com.
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 elixir-lang-core+unsubscribe@googlegroups.com.
This is really, really hard to do because it would overcomplicate the language grammar, as it would have to take comments into account at every step. I am not even sure if it is possible. If someone wants to try it out though. :)
That's why most tools end-up handling comments on the side, separated from parsing.
José ValimSkype: jv.ptecFounder and Director of R&D
On Sun, Sep 16, 2018 at 6:59 PM, Steve Morin <steve...@gmail.com> wrote:
Wanted to see what peoples thoughts are about adding comments to the AST.
One use-case is to be able to parse and manipulate Source files outside of just macros but in that case you would want to be able to preserve comments.
E.g. Read a source file, manipulate it, write that source file back to a file.
This would allow people/tooling to use elixir to parse and manipulate source files.
If this might disturb existing consumers of the AST maybe this could be added as a option to existing Macro functions so that I could be turned on for people with this use-case.
--
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 elixir-lang-co...@googlegroups.com.
--
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 elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J4%2BcTqcXH_ESJL2_o7rv5OJxkf_yJDpVAH%3DCjH2mmO7w%40mail.gmail.com.
HeyI'm a little out of touch with this area, but isn't this what we previously did? I remember comments being stored in meta during the creation of the formatter. Or did I make that up?Cheers,Louis
On Mon, 17 Sep 2018 at 19:17 José Valim <jose....@plataformatec.com.br> wrote:
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.Once all the details are ironed out, then somebody can go ahead and fully implement it. :)--
--
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 elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J4%2BcTqcXH_ESJL2_o7rv5OJxkf_yJDpVAH%3DCjH2mmO7w%40mail.gmail.com.
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 elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFAk6UQJbbMcD2xkwJFLPM%3DbASSnOqL6ihSdUQEMpuKNGg%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LmVcoPq7fRkJY5ErJ4N93Bd8-9erEByNETt%2BLN5DZuYA%40mail.gmail.com.
Yes being part of the metadata would be great. Need to look around/research and see what other people have done. Just not losing the data would be great.
I don't think we ever stored them in meta. But even if we did, we would probably have done it in the formatter, and we should likely move it somewhere public.
On Mon, Sep 17, 2018 at 8:37 PM, Louis Pilfold <louisp...@gmail.com> wrote:
HeyI'm a little out of touch with this area, but isn't this what we previously did? I remember comments being stored in meta during the creation of the formatter. Or did I make that up?Cheers,Louis
On Mon, 17 Sep 2018 at 19:17 José Valim <jose....@plataformatec.com.br> wrote:
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.Once all the details are ironed out, then somebody can go ahead and fully implement it. :)--
--
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 elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J4%2BcTqcXH_ESJL2_o7rv5OJxkf_yJDpVAH%3DCjH2mmO7w%40mail.gmail.com.
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 elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFAk6UQJbbMcD2xkwJFLPM%3DbASSnOqL6ihSdUQEMpuKNGg%40mail.gmail.com.
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 elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LmVcoPq7fRkJY5ErJ4N93Bd8-9erEByNETt%2BLN5DZuYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/5f1a035a-527d-4b60-9d24-12f376835e01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-l...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/5f1a035a-527d-4b60-9d24-12f376835e01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
# Let's return just an atom for now
:foo
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/a13ad0ff-4f42-44f9-91f5-8eacaa27450d%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/0ab97ebf-39bf-4bcc-a137-49be7ed03f7c%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/db687fa7-7377-4354-b794-7d5be9f6b240%40googlegroups.com.
We could and that's the approach we use in the formatter but we can't use it generally because it would break stuff like keyword lists (as the first element is now a tuple __block__ and no longer an atom).
--
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 elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/c54d286d-cf7d-4631-b00a-810b680574c3%40googlegroups.com.
I am sorry but I cannot understand what you are talking about.If you are saying that having lists and tuples being literals are weird and that they should be regular ASTs (i.e. three elem tuples), then I recommend you to try doing those changes in an Elixir fork and see how it impacts the language.
def traverse({left, meta, right})
def traverse({one, two})def traverse([_ | _] = list)
def traverse(other)
--
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 elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JDiCU2-viWn06FOwLAQKTZ-ufTPdihUn8UnaTcC5ZHfw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/D78F2CE6-1EA1-4C16-8EDE-37FBD7005ED7%40gmail.com.
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAPxhEGf%3DFmRMxGqb8QDMNSFT56nuP2%2BeiVgVcKnmLL5ob5g%3Dsw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BOh2VjzioKzbNN4bAZBmtUq2eydr76YMZj45Fzm1Z3fw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAPxhEGfj5WKsj29NzHOA8zrcazv20447soOdYwJWYXupXCOCRA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KavKX4kN3rsLZ7ajm_B6yOqUKN0LLRokg_M5vNe%2B8MQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAPxhEGfcLvMfxZZ4PL59FP%2BsD%3Ds1QXCfuwvxSyyD2FNsGurtxA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JhmOz8vUbJZNA3Ta_-61Rrt%2BpL2ZwVtbvsqg2bBsMD%2BA%40mail.gmail.com.
quote do # one is the lonliest number
1 2 # two is the smallest prime
3 # I am at the end
end
{:__block__, [comments: [0 => "one is the lonliest number", 3 =>
"two is the smallest prime", 6 => "I am at the end"]], [1,2,3]}
--
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 elixir-lang-co...@googlegroups.com.
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.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-l...@googlegroups.com.
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.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/6fa656e1-6eec-4ad9-be50-e0f503edf58a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/6fa656e1-6eec-4ad9-be50-e0f503edf58a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.