[elixir-core:8616] Give warning on unused require

[Mário Guimarães]

Hi,

I suggest for Elixir to warn on unused requires, like it does for unused 
aliases.

Thanks 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/a807db74-88f9-43f0-bbcb-8c967a48e837%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8615] Missing tuple access idioms

[Mário Guimarães]

I guess there will be always different tastes regarding this subject :-)

sexta-feira, 5 de Abril de 2019 às 13:48:32 UTC+1, Andrea Leopardi escreveu:
>
> Often times matching on the tuple size can make your program safer since 
> it will crash on unexpected inputs. In cases like the one you mentioned, I 
> would go with |> Enum.map(fn {x, _, _} -> x end).
>
> On Fri, 5 Apr 2019 at 14:46, Mário Guimarães  > wrote:
>
>> Hi José
>>
>> there are occasions like when doing ... |> Enum.map() |> ... where 
>> pattern matching does not apply, and .. |> Enum.map((&1,0)) |> ... is 
>> much less readable.
>>
>> It was regarding these cases that I thought about tuple accessors.
>>
>> Mário Guimarães
>>
>> sexta-feira, 5 de Abril de 2019 às 12:42:11 UTC+1, José Valim escreveu:
>>>
>>> But perhaps, the most important, is that generally you should be pattern 
>>> matching on tuples.
>>>
>>> Most of the times, you know exactly the size of the tuple you are 
>>> working with, and pattern matching on it is more intention revealing.
>>>
>>> If you have large tuples and the size may change, then sure, pattern 
>>> matching is not a good idea, but then the Record module becomes handy. 
>>> Record allows you to work with tuples and give also them names, and the 
>>> names are a better API than relying on indexes.
>>>
>>> *José Valim*
>>> www.plataformatec.com.br
>>> Skype: jv.ptec
>>> Founder and Director of R
>>>
>>>
>>> On Fri, Apr 5, 2019 at 1:13 PM Arjan Scherpenisse  
>>> wrote:
>>>
>> If you really want this, you could metaprogram it yourself ;-)

 defmodule TupleAccess do
   @names ~w(first second third fourth fifth sixth seventh eight ninth 
 tenth)a

   for {name, index} <- Enum.with_index(@names) do
 def unquote(name)(tuple) do
   elem(tuple, unquote(index))
 end
   end
 end

 iex(5)> import TupleAccess
 TupleAccess
 iex(6)> first({:a})
 :a
 iex(7)> first({:a, :b})
 :a
 iex(8)> second({:a, :b})
 :b


 On Friday, April 5, 2019 at 1:05:35 PM UTC+2, Louis Pilfold wrote:
>
> Hey
>
> We have elem/2, which is quite clear and more concise.
>
> We don't need specific functions for each index because we are not 
> limited by a static type system and so the index does not need to be 
> known 
> at compile time.
>
> Cheers,
> Louis
>
> On Fri, 5 Apr 2019, 11:29 Mário Guimarães,  
> wrote:
>
>> Hello,
>>
>> any reason why there are no easy readable idioms like
>>
>> first, snd, third, ..., tenth (I guess is enough)
>>
>> to access tuples?
>>
>> Thanks
>>
>> -- 
>> 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-l...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/75b06fc7-5be0-4070-8c49-6e2fb5779ea3%40googlegroups.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-l...@googlegroups.com.

>>> To view this discussion on the web visit 
 https://groups.google.com/d/msgid/elixir-lang-core/da9cc177-513d-4683-8f4e-1c8b9c8286ca%40googlegroups.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-l...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/876d9efd-f721-431a-b4c5-620876f2aaad%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
>
> Andrea Leopardi
> an.le...@gmail.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-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [elixir-core:8613] Missing tuple access idioms

[Andrea Leopardi]

Often times matching on the tuple size can make your program safer since it
will crash on unexpected inputs. In cases like the one you mentioned, I
would go with |> Enum.map(fn {x, _, _} -> x end).

On Fri, 5 Apr 2019 at 14:46, Mário Guimarães 
wrote:

> Hi José
>
> there are occasions like when doing ... |> Enum.map() |> ... where
> pattern matching does not apply, and .. |> Enum.map((&1,0)) |> ... is
> much less readable.
>
> It was regarding these cases that I thought about tuple accessors.
>
> Mário Guimarães
>
> sexta-feira, 5 de Abril de 2019 às 12:42:11 UTC+1, José Valim escreveu:
>>
>> But perhaps, the most important, is that generally you should be pattern
>> matching on tuples.
>>
>> Most of the times, you know exactly the size of the tuple you are working
>> with, and pattern matching on it is more intention revealing.
>>
>> If you have large tuples and the size may change, then sure, pattern
>> matching is not a good idea, but then the Record module becomes handy.
>> Record allows you to work with tuples and give also them names, and the
>> names are a better API than relying on indexes.
>>
>> *José Valim*
>> www.plataformatec.com.br
>> Skype: jv.ptec
>> Founder and Director of R
>>
>>
>> On Fri, Apr 5, 2019 at 1:13 PM Arjan Scherpenisse 
>> wrote:
>>
> If you really want this, you could metaprogram it yourself ;-)
>>>
>>> defmodule TupleAccess do
>>>   @names ~w(first second third fourth fifth sixth seventh eight ninth
>>> tenth)a
>>>
>>>   for {name, index} <- Enum.with_index(@names) do
>>> def unquote(name)(tuple) do
>>>   elem(tuple, unquote(index))
>>> end
>>>   end
>>> end
>>>
>>> iex(5)> import TupleAccess
>>> TupleAccess
>>> iex(6)> first({:a})
>>> :a
>>> iex(7)> first({:a, :b})
>>> :a
>>> iex(8)> second({:a, :b})
>>> :b
>>>
>>>
>>> On Friday, April 5, 2019 at 1:05:35 PM UTC+2, Louis Pilfold wrote:

 Hey

 We have elem/2, which is quite clear and more concise.

 We don't need specific functions for each index because we are not
 limited by a static type system and so the index does not need to be known
 at compile time.

 Cheers,
 Louis

 On Fri, 5 Apr 2019, 11:29 Mário Guimarães, 
 wrote:

> Hello,
>
> any reason why there are no easy readable idioms like
>
> first, snd, third, ..., tenth (I guess is enough)
>
> to access tuples?
>
> Thanks
>
> --
> 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-l...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/75b06fc7-5be0-4070-8c49-6e2fb5779ea3%40googlegroups.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-l...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/elixir-lang-core/da9cc177-513d-4683-8f4e-1c8b9c8286ca%40googlegroups.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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/876d9efd-f721-431a-b4c5-620876f2aaad%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

Andrea Leopardi
an.leopa...@gmail.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-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2B%2B%3Dv%2BD7a9AV9KZK%2BQWUtcfL_R1yhSab_i3dGbzVNytxuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8613] Missing tuple access idioms

[Mário Guimarães]

Hi José

there are occasions like when doing ... |> Enum.map() |> ... where 
pattern matching does not apply, and .. |> Enum.map((&1,0)) |> ... is 
much less readable.

It was regarding these cases that I thought about tuple accessors.

Mário Guimarães

sexta-feira, 5 de Abril de 2019 às 12:42:11 UTC+1, José Valim escreveu:
>
> But perhaps, the most important, is that generally you should be pattern 
> matching on tuples.
>
> Most of the times, you know exactly the size of the tuple you are working 
> with, and pattern matching on it is more intention revealing.
>
> If you have large tuples and the size may change, then sure, pattern 
> matching is not a good idea, but then the Record module becomes handy. 
> Record allows you to work with tuples and give also them names, and the 
> names are a better API than relying on indexes.
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
>
> On Fri, Apr 5, 2019 at 1:13 PM Arjan Scherpenisse  > wrote:
>
>> If you really want this, you could metaprogram it yourself ;-)
>>
>> defmodule TupleAccess do
>>   @names ~w(first second third fourth fifth sixth seventh eight ninth 
>> tenth)a
>>
>>   for {name, index} <- Enum.with_index(@names) do
>> def unquote(name)(tuple) do
>>   elem(tuple, unquote(index))
>> end
>>   end
>> end
>>
>> iex(5)> import TupleAccess
>> TupleAccess
>> iex(6)> first({:a})
>> :a
>> iex(7)> first({:a, :b})
>> :a
>> iex(8)> second({:a, :b})
>> :b
>>
>>
>> On Friday, April 5, 2019 at 1:05:35 PM UTC+2, Louis Pilfold wrote:
>>>
>>> Hey
>>>
>>> We have elem/2, which is quite clear and more concise.
>>>
>>> We don't need specific functions for each index because we are not 
>>> limited by a static type system and so the index does not need to be known 
>>> at compile time.
>>>
>>> Cheers,
>>> Louis
>>>
>>> On Fri, 5 Apr 2019, 11:29 Mário Guimarães,  
>>> wrote:
>>>
 Hello,

 any reason why there are no easy readable idioms like

 first, snd, third, ..., tenth (I guess is enough)

 to access tuples?

 Thanks

 -- 
 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-l...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/elixir-lang-core/75b06fc7-5be0-4070-8c49-6e2fb5779ea3%40googlegroups.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-l...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/da9cc177-513d-4683-8f4e-1c8b9c8286ca%40googlegroups.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/876d9efd-f721-431a-b4c5-620876f2aaad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8611] Missing tuple access idioms

[José Valim]

But perhaps, the most important, is that generally you should be pattern
matching on tuples.

Most of the times, you know exactly the size of the tuple you are working
with, and pattern matching on it is more intention revealing.

If you have large tuples and the size may change, then sure, pattern
matching is not a good idea, but then the Record module becomes handy.
Record allows you to work with tuples and give also them names, and the
names are a better API than relying on indexes.

*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R


On Fri, Apr 5, 2019 at 1:13 PM Arjan Scherpenisse 
wrote:

> If you really want this, you could metaprogram it yourself ;-)
>
> defmodule TupleAccess do
>   @names ~w(first second third fourth fifth sixth seventh eight ninth
> tenth)a
>
>   for {name, index} <- Enum.with_index(@names) do
> def unquote(name)(tuple) do
>   elem(tuple, unquote(index))
> end
>   end
> end
>
> iex(5)> import TupleAccess
> TupleAccess
> iex(6)> first({:a})
> :a
> iex(7)> first({:a, :b})
> :a
> iex(8)> second({:a, :b})
> :b
>
>
> On Friday, April 5, 2019 at 1:05:35 PM UTC+2, Louis Pilfold wrote:
>>
>> Hey
>>
>> We have elem/2, which is quite clear and more concise.
>>
>> We don't need specific functions for each index because we are not
>> limited by a static type system and so the index does not need to be known
>> at compile time.
>>
>> Cheers,
>> Louis
>>
>> On Fri, 5 Apr 2019, 11:29 Mário Guimarães, 
>> wrote:
>>
>>> Hello,
>>>
>>> any reason why there are no easy readable idioms like
>>>
>>> first, snd, third, ..., tenth (I guess is enough)
>>>
>>> to access tuples?
>>>
>>> Thanks
>>>
>>> --
>>> 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-l...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/elixir-lang-core/75b06fc7-5be0-4070-8c49-6e2fb5779ea3%40googlegroups.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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/da9cc177-513d-4683-8f4e-1c8b9c8286ca%40googlegroups.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L32XGv%2B4KvbshsRhzO9bp1F8k55j7usObpJn7Z31zCFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8611] Missing tuple access idioms

[Arjan Scherpenisse]

If you really want this, you could metaprogram it yourself ;-)

defmodule TupleAccess do
  @names ~w(first second third fourth fifth sixth seventh eight ninth 
tenth)a

  for {name, index} <- Enum.with_index(@names) do
def unquote(name)(tuple) do
  elem(tuple, unquote(index))
end
  end
end

iex(5)> import TupleAccess
TupleAccess
iex(6)> first({:a})
:a
iex(7)> first({:a, :b})
:a
iex(8)> second({:a, :b})
:b


On Friday, April 5, 2019 at 1:05:35 PM UTC+2, Louis Pilfold wrote:
>
> Hey
>
> We have elem/2, which is quite clear and more concise.
>
> We don't need specific functions for each index because we are not limited 
> by a static type system and so the index does not need to be known at 
> compile time.
>
> Cheers,
> Louis
>
> On Fri, 5 Apr 2019, 11:29 Mário Guimarães,  > wrote:
>
>> Hello,
>>
>> any reason why there are no easy readable idioms like
>>
>> first, snd, third, ..., tenth (I guess is enough)
>>
>> to access tuples?
>>
>> Thanks
>>
>> -- 
>> 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-l...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/75b06fc7-5be0-4070-8c49-6e2fb5779ea3%40googlegroups.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/da9cc177-513d-4683-8f4e-1c8b9c8286ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8609] Missing tuple access idioms

[Louis Pilfold]

Hey

We have elem/2, which is quite clear and more concise.

We don't need specific functions for each index because we are not limited
by a static type system and so the index does not need to be known at
compile time.

Cheers,
Louis

On Fri, 5 Apr 2019, 11:29 Mário Guimarães, 
wrote:

> Hello,
>
> any reason why there are no easy readable idioms like
>
> first, snd, third, ..., tenth (I guess is enough)
>
> to access tuples?
>
> Thanks
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/75b06fc7-5be0-4070-8c49-6e2fb5779ea3%40googlegroups.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CABu8xFC00eHW29-46dMr%3DbERc_CP-4OAp2pgntuCCgtevm%2Bt5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[elixir-core:8609] Missing tuple access idioms

[Mário Guimarães]

Hello,

any reason why there are no easy readable idioms like

first, snd, third, ..., tenth (I guess is enough)

to access tuples?

Thanks

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/75b06fc7-5be0-4070-8c49-6e2fb5779ea3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:8608] Proposal: Comments in AST

[Arjan Scherpenisse]

I understand your hesitance.. basically, what I think would be really 
valuable is a way to transform an AST back to code. That would enable a 
whole class of refactoring tools: renaming a function (including its call 
sites), inlining variables, etc, etc. Maybe I'm just spoiled with having 
used the IntelliJ IDEs for a while.. :-)

I think the formatter_metadata: true annotated AST is already a good step 
in this direction, the only thing missing there is a way to attach comments.

Arjan


On Thursday, April 4, 2019 at 9:31:16 AM UTC+2, José Valim wrote:
>
> For what purpose we would introduce another AST representation?
>
> I am really hesitant to introduce another interpretation of your AST 
> unless it is really justified. I am even concerned with exposing the 
> formatter AST because if there is a formatter bug and we need to change the 
> formatter AST to fix it, then we will suddenly break people's code and be 
> unable to improve the formatter, which is the main reason why the formatter 
> AST exists today in the first place.
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R
>
>
> On Thu, Apr 4, 2019 at 9:26 AM Arjan Scherpenisse  > wrote:
>
>> Yes so maybe the route would be to define an "extended AST" format, an 
>> AST which cannot directly be used to compile or evaluate Elixir 
>> expressions, but can always be reduced to the "official" AST format?
>>
>> This extended AST could include everything that the formatter_metadata: 
>> true option currently includes, but also comment(s) for the nodes (trailing 
>> comments as well), basically, everything to re-create the original source 
>> code (given that the original was formatted, we should not add white space 
>> to this AST). As a bonus we could delay the creation of non-existing atoms 
>> to the conversion to the "official" AST, so this format could be used for 
>> DSL that rely on new identifiers but without the atom leakage.
>>
>> What do you think?
>> Arjan
>>
>> On Wednesday, April 3, 2019 at 10:57:04 PM UTC+2, José Valim wrote:
>>>
>>> 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).
>>>
>>>
>>> *José Valim*
>>> www.plataformatec.com.br
>>> Skype: jv.ptec
>>> Founder and Director of R
>>>
>>>
>>> On Wed, Apr 3, 2019 at 10:53 PM Arjan Scherpenisse  
>>> wrote:
>>>
 One thing that comes to mind for "simple value" cases like this: we 
 could use the existing :__block__ ast node with a single child as nodes 
 for 
 simple values which have metadata attributes. AFAIK __block__ ast nodes 
 now 
 always have > 1 child.

 This works:

 iex(7)> {:__block__, [], [:a]} |> Macro.to_string 
 ":a"

 And this as well:

 iex(10)> {:__block__, [], [123]} |> Code.eval_quoted()
 {123, []}



 On Wednesday, April 3, 2019 at 9:55:22 PM UTC+2, Arjan Scherpenisse 
 wrote:
>
> Thanks José,
>
> This is indeed a topic of interest to me. Actually, part of my talk in 
> Prague coming tuesday will be about this. I'll let it simmer for now and 
> maybe we can have a chat during the conference!
>
> cheers, Arjan
>
> On Wednesday, April 3, 2019 at 9:07:24 PM UTC+2, José Valim wrote:
>>
>> Hi Arjan,
>>
>> I don't believe there was any progress here. Storing it in the AST 
>> would be hard because some nodes have no metadata slot, so it would be 
>> tricky in situations like this:
>>
>> # Let's return just an atom for now
>> :foo
>>
>>
>> However, we do have the ability to return comments from tokenizer and 
>> the formatter use this feature:
>>
>>
>> https://github.com/elixir-lang/elixir/blob/master/lib/elixir/lib/code/formatter.ex#L205-L206
>>
>> Note however those are private APIs but we will be glad to add a new 
>> API or an option to one of the functions in the Code module that return 
>> the 
>> AST + comments from a string. Feel free to experiment with the above and 
>> submit a proposal as you see fit.
>>
>> *José Valim*
>> www.plataformatec.com.br
>> Skype: jv.ptec
>> Founder and Director of R
>>
>>
>> On Wed, Apr 3, 2019 at 8:27 PM Arjan Scherpenisse <
>> scherp...@gmail.com> wrote:
>>
>>> Hi Steve, just stumbled on this, do you know if anything ever 
>>> happened to this?
>>>
>>> On Sunday, September 23, 2018 at 1:10:38 AM UTC+2, Steve Morin wrote:

 Tried on Slack but I'll try freenode next

 On Fri, Sep 21, 2018 at 10:47 AM OvermindDL1  
 wrote:

> #elixir-lang on freenode for note*
>
> On Friday, September 21, 2018 at 11:47:25 AM UTC-6, OvermindDL1 
> wrote:
>>
>> IRC would be a great