Re: [elixir-core:7916] Introduce Sum Types

[OvermindDL1]

Lol!  I thought that name looked familiar.  ^.^

You should, I know there are a couple of 'incomplete' implementations 
around (though that one that I cannot remember the name of was the 
closest...).  :-)


On Monday, February 26, 2018 at 3:52:32 PM UTC-7, Louis Pilfold wrote:
>
> That would be the library I started writing that I was looking for an 
> alternative to finishing :D
>
> Guess I should finish it!
>
> On Mon, 26 Feb 2018, 22:02 OvermindDL1,  
> wrote:
>
>> So something more like https://github.com/lpil/sum or so (undocumented, 
>> but it looks right, it's the first thing I found via a github search).
>>
>> There is one specific one I'm thinking of but can't for the life of me 
>> remember it's name...  I wish hex.pm had the ability to search module 
>> and function names in a libraries public API...  >.>
>>
>> Either way, it's not hard to write a library to support it though.  :-)
>>
>>
>> On Sunday, February 25, 2018 at 9:58:44 AM UTC-7, Louis Pop wrote:
>>
>>> If I recall correctly this library wraps the values and does not offer 
>>> compile time checks, which is the inverse of what I'm after.
>>>
>>> I want unwrapped values and compile time checks :)
>>>
>>> Cheers,
>>> Louis
>>>
>>> On Sun, 25 Feb 2018, 16:00 OvermindDL1,  wrote:
>>>
>> There are at least 2 others that I know of, and I can find those for you 
 too tomorrow if you want them, they have different features and focuses, 
 but the one that immediately comes to mind is:  
 https://github.com/expede/algae

 Expede on GitHub has a lot of cool and useful little 'core' elixir 
 libraries in my opinion.

 On Feb 24, 2018 06:46, "Louis Pilfold"  wrote:

>>> Hi
>
> I started to implement such a library, but I would much prefer to use 
> an existing one. I was unable to find any, wild you be able to share some 
> links?
>
> Thanks,
> Louis
>
> On Fri, 23 Feb 2018, 18:09 OvermindDL1,  wrote:
>
 There are some library that add sum types to Elixir that do 'some' 
>> compile-time checks (like case's and so forth).  It would be useful 
>> built 
>> in to elixir (though not any of the current library implementations) but 
>> the libraries already do support much of it.
>>
>>
>> On Friday, February 16, 2018 at 6:35:03 AM UTC-7, Ben Wilson wrote:
>>>
>>> Can you elaborate on the safety provided by doing `%Struct{} = ` on 
>>> a function? There are no compile time checks that calls to that 
>>> function 
>>> are actually of that struct type, just runtime checks on the data. Put 
>>> another way this isn't really a type check, but an assertion.
>>>
>>> On Friday, February 16, 2018 at 6:38:07 AM UTC-5, 
>>> maen...@joshmartin.ch wrote:

 Hey Louis,

 I think it should include compile time checks. Mostly I would 
 expect those for function headers, case blocks and with blocks.

 Dialyzer already checks many of those conditions, but I would like 
 to go a step further.
 Your mentioned library looks really interesting. Making it work 
 together with existing type specifications would be really cool.

 With for example structs, I can achieve safety really easy by 
 adding *%Struct{} = my_input* to the function header.

 I would like to have a mechanism that works similarly, but 
 additionally checks uncovered types of a sum. (If you would for 
 example not 
 cover the None of a Maybe)

 I think that this could tremendously improve the code quality.

 Cheers,
 Jony

 Am Freitag, 16. Februar 2018 11:57:00 UTC+1 schrieb Louis Pilfold:
>
> Hey Jony
>
> Would this involve some form of compile time type checking for 
> these values? If not we already have them in the form of tuples.
>
> @type result :: {:ok, string()} | {:error, string()}
>
> If you want compile time checks this would be more difficult. I've 
> experimented a little with compile time checks with macros, check it 
> out 
> here -> https://github.com/lpil/sum
>
> Cheers,
> Louis
>
> On Fri, 16 Feb 2018 at 10:33  wrote:
>
>> Hi all,
>>
>> First I want to thank you all for your great work on the elixir 
>> language!
>>
>> Have there been some thoughts to introduce Tagged Unions into 
>> elixir?
>> I would really love to use sum types like Either or simple enums 
>> in my daily work and have some support of the language in handling 
>> them.
>>
>> What do you think about this?
>>
>> Cheers,
>> 

Re: [elixir-core:7914] Introduce Sum Types

[Louis Pilfold]

That would be the library I started writing that I was looking for an
alternative to finishing :D

Guess I should finish it!

On Mon, 26 Feb 2018, 22:02 OvermindDL1,  wrote:

> So something more like https://github.com/lpil/sum or so (undocumented,
> but it looks right, it's the first thing I found via a github search).
>
> There is one specific one I'm thinking of but can't for the life of me
> remember it's name...  I wish hex.pm had the ability to search module and
> function names in a libraries public API...  >.>
>
> Either way, it's not hard to write a library to support it though.  :-)
>
>
> On Sunday, February 25, 2018 at 9:58:44 AM UTC-7, Louis Pop wrote:
>
>> If I recall correctly this library wraps the values and does not offer
>> compile time checks, which is the inverse of what I'm after.
>>
>> I want unwrapped values and compile time checks :)
>>
>> Cheers,
>> Louis
>>
>> On Sun, 25 Feb 2018, 16:00 OvermindDL1,  wrote:
>>
> There are at least 2 others that I know of, and I can find those for you
>>> too tomorrow if you want them, they have different features and focuses,
>>> but the one that immediately comes to mind is:
>>> https://github.com/expede/algae
>>>
>>> Expede on GitHub has a lot of cool and useful little 'core' elixir
>>> libraries in my opinion.
>>>
>>> On Feb 24, 2018 06:46, "Louis Pilfold"  wrote:
>>>
>> Hi

 I started to implement such a library, but I would much prefer to use
 an existing one. I was unable to find any, wild you be able to share some
 links?

 Thanks,
 Louis

 On Fri, 23 Feb 2018, 18:09 OvermindDL1,  wrote:

>>> There are some library that add sum types to Elixir that do 'some'
> compile-time checks (like case's and so forth).  It would be useful built
> in to elixir (though not any of the current library implementations) but
> the libraries already do support much of it.
>
>
> On Friday, February 16, 2018 at 6:35:03 AM UTC-7, Ben Wilson wrote:
>>
>> Can you elaborate on the safety provided by doing `%Struct{} = ` on a
>> function? There are no compile time checks that calls to that function 
>> are
>> actually of that struct type, just runtime checks on the data. Put 
>> another
>> way this isn't really a type check, but an assertion.
>>
>> On Friday, February 16, 2018 at 6:38:07 AM UTC-5,
>> maen...@joshmartin.ch wrote:
>>>
>>> Hey Louis,
>>>
>>> I think it should include compile time checks. Mostly I would expect
>>> those for function headers, case blocks and with blocks.
>>>
>>> Dialyzer already checks many of those conditions, but I would like
>>> to go a step further.
>>> Your mentioned library looks really interesting. Making it work
>>> together with existing type specifications would be really cool.
>>>
>>> With for example structs, I can achieve safety really easy by adding 
>>> *%Struct{}
>>> = my_input* to the function header.
>>>
>>> I would like to have a mechanism that works similarly, but
>>> additionally checks uncovered types of a sum. (If you would for example 
>>> not
>>> cover the None of a Maybe)
>>>
>>> I think that this could tremendously improve the code quality.
>>>
>>> Cheers,
>>> Jony
>>>
>>> Am Freitag, 16. Februar 2018 11:57:00 UTC+1 schrieb Louis Pilfold:

 Hey Jony

 Would this involve some form of compile time type checking for
 these values? If not we already have them in the form of tuples.

 @type result :: {:ok, string()} | {:error, string()}

 If you want compile time checks this would be more difficult. I've
 experimented a little with compile time checks with macros, check it 
 out
 here -> https://github.com/lpil/sum

 Cheers,
 Louis

 On Fri, 16 Feb 2018 at 10:33  wrote:

> Hi all,
>
> First I want to thank you all for your great work on the elixir
> language!
>
> Have there been some thoughts to introduce Tagged Unions into
> elixir?
> I would really love to use sum types like Either or simple enums
> in my daily work and have some support of the language in handling 
> them.
>
> What do you think about this?
>
> Cheers,
> Jony
>
> --
> 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
> 

Re: [elixir-core:7913] Re: [Proposal] Kernel.is_module?/1

[Thomas Cioppettini]

OvermindDL1, `function_exported?` was the second method I tried, but the
caveat of it needing to be loaded in memory causes too many issues IMO.
That is why I settled on the current version I linked to above, which is a
more direct variant of what you are suggesting.

On Mon, Feb 26, 2018 at 5:13 PM, OvermindDL1  wrote:

> For note, for a quick-check if a module exists I just do something like:
>
> ```elixir
> ╰─➤  iex
> Erlang/OTP 20 [erts-9.1] [source] [64-bit] [smp:2:2] [ds:2:2:10]
> [async-threads:10] [hipe] [kernel-poll:false]
>
> Interactive Elixir (1.6.1) - press Ctrl+C to exit (type h() ENTER for
> help)
> iex(1)> function_exported?(String, :module_info, 0)
> true
> iex(2)> function_exported?(SomeModule, :module_info, 0)
> false
> ```
>
> This *only* works on modules already loaded in memory (which the
> afore-mentioned `Code.ensure_loaded/1` and `Code.ensure_compiled/1` do in
> various ways), but in production running in embedded mode that's fine (it's
> always the case for me, but be aware of your cases).
> The reason this works as that the BEAM VM requires a `module_info/0`
> function on the BEAM module as it uses it for various things, so it's easy
> just to test for the existence of this function.
>
> You can always try calling `blahmodule.module_info()` and catch the
> exception if it doesn't exist, this should force loading so should be
> faster then the `Code.*` calls but still not as fast as
> `function_exported?` though.
>
> On Saturday, February 24, 2018 at 7:49:40 PM UTC-7, t...@scalpel.com
> wrote:
>>
>> It is more difficult than you would expect to check if something in
>> Elixir is a module. I think it is fairly reasonable to build this
>> functionality into the language. The best way I've found to do this is to
>> call a function on the value and rescue from the `UndefinedFunctionError`.
>> This feels a bit hacky to me and I think there should be a more elegant
>> solution.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "elixir-lang-core" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elixir-lang-core/T3hCNAKmrds/unsubscribe.
> To unsubscribe from this group and all its topics, 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/f0514cb7-18d1-4d73-800e-
> 35b56d4322d3%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/CANhOUugaiV40Hcr7UGb_KzD_9JJzDVUVK2_UhSB4TXSKBcog5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[elixir-core:7913] Re: [Proposal] Kernel.is_module?/1

[OvermindDL1]

For note, for a quick-check if a module exists I just do something like:

```elixir
╰─➤  iex 
Erlang/OTP 20 [erts-9.1] [source] [64-bit] [smp:2:2] [ds:2:2:10] 
[async-threads:10] [hipe] [kernel-poll:false] 

Interactive Elixir (1.6.1) - press Ctrl+C to exit (type h() ENTER for help) 
iex(1)> function_exported?(String, :module_info, 0) 
true 
iex(2)> function_exported?(SomeModule, :module_info, 0) 
false
```

This *only* works on modules already loaded in memory (which the 
afore-mentioned `Code.ensure_loaded/1` and `Code.ensure_compiled/1` do in 
various ways), but in production running in embedded mode that's fine (it's 
always the case for me, but be aware of your cases).
The reason this works as that the BEAM VM requires a `module_info/0` 
function on the BEAM module as it uses it for various things, so it's easy 
just to test for the existence of this function.

You can always try calling `blahmodule.module_info()` and catch the 
exception if it doesn't exist, this should force loading so should be 
faster then the `Code.*` calls but still not as fast as 
`function_exported?` though.

On Saturday, February 24, 2018 at 7:49:40 PM UTC-7, t...@scalpel.com wrote:
>
> It is more difficult than you would expect to check if something in Elixir 
> is a module. I think it is fairly reasonable to build this functionality 
> into the language. The best way I've found to do this is to call a function 
> on the value and rescue from the `UndefinedFunctionError`. This feels a bit 
> hacky to me and I think there should be a more elegant solution.
>

-- 
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/f0514cb7-18d1-4d73-800e-35b56d4322d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7912] Introduce Sum Types

[OvermindDL1]

So something more like https://github.com/lpil/sum or so (undocumented, but 
it looks right, it's the first thing I found via a github search).

There is one specific one I'm thinking of but can't for the life of me 
remember it's name...  I wish hex.pm had the ability to search module and 
function names in a libraries public API...  >.>

Either way, it's not hard to write a library to support it though.  :-)


On Sunday, February 25, 2018 at 9:58:44 AM UTC-7, Louis Pop wrote:
>
> If I recall correctly this library wraps the values and does not offer 
> compile time checks, which is the inverse of what I'm after.
>
> I want unwrapped values and compile time checks :)
>
> Cheers,
> Louis
>
> On Sun, 25 Feb 2018, 16:00 OvermindDL1,  
> wrote:
>
>> There are at least 2 others that I know of, and I can find those for you 
>> too tomorrow if you want them, they have different features and focuses, 
>> but the one that immediately comes to mind is:  
>> https://github.com/expede/algae
>>
>> Expede on GitHub has a lot of cool and useful little 'core' elixir 
>> libraries in my opinion.
>>
>> On Feb 24, 2018 06:46, "Louis Pilfold"  
>> wrote:
>>
>>> Hi
>>>
>>> I started to implement such a library, but I would much prefer to use an 
>>> existing one. I was unable to find any, wild you be able to share some 
>>> links?
>>>
>>> Thanks,
>>> Louis
>>>
>>> On Fri, 23 Feb 2018, 18:09 OvermindDL1, >> > wrote:
>>>
 There are some library that add sum types to Elixir that do 'some' 
 compile-time checks (like case's and so forth).  It would be useful built 
 in to elixir (though not any of the current library implementations) but 
 the libraries already do support much of it.


 On Friday, February 16, 2018 at 6:35:03 AM UTC-7, Ben Wilson wrote:
>
> Can you elaborate on the safety provided by doing `%Struct{} = ` on a 
> function? There are no compile time checks that calls to that function 
> are 
> actually of that struct type, just runtime checks on the data. Put 
> another 
> way this isn't really a type check, but an assertion.
>
> On Friday, February 16, 2018 at 6:38:07 AM UTC-5, 
> maen...@joshmartin.ch wrote:
>>
>> Hey Louis,
>>
>> I think it should include compile time checks. Mostly I would expect 
>> those for function headers, case blocks and with blocks.
>>
>> Dialyzer already checks many of those conditions, but I would like to 
>> go a step further.
>> Your mentioned library looks really interesting. Making it work 
>> together with existing type specifications would be really cool.
>>
>> With for example structs, I can achieve safety really easy by adding 
>> *%Struct{} 
>> = my_input* to the function header.
>>
>> I would like to have a mechanism that works similarly, but 
>> additionally checks uncovered types of a sum. (If you would for example 
>> not 
>> cover the None of a Maybe)
>>
>> I think that this could tremendously improve the code quality.
>>
>> Cheers,
>> Jony
>>
>> Am Freitag, 16. Februar 2018 11:57:00 UTC+1 schrieb Louis Pilfold:
>>>
>>> Hey Jony
>>>
>>> Would this involve some form of compile time type checking for these 
>>> values? If not we already have them in the form of tuples.
>>>
>>> @type result :: {:ok, string()} | {:error, string()}
>>>
>>> If you want compile time checks this would be more difficult. I've 
>>> experimented a little with compile time checks with macros, check it 
>>> out 
>>> here -> https://github.com/lpil/sum
>>>
>>> Cheers,
>>> Louis
>>>
>>> On Fri, 16 Feb 2018 at 10:33  wrote:
>>>
 Hi all,

 First I want to thank you all for your great work on the elixir 
 language!

 Have there been some thoughts to introduce Tagged Unions into 
 elixir?
 I would really love to use sum types like Either or simple enums in 
 my daily work and have some support of the language in handling them.

 What do you think about this?

 Cheers,
 Jony

 -- 
 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/4052d8d9-6eda-46c9-b259-fb0f2e041120%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> -- 

Re: [elixir-core:7910] Enhancement request: parse character offsets for AST node

[Louis Pilfold]

Hi there

Given we have the formatter now I would be tempted to avoid editing strings
and instead update the AST of the file, render that to a string, format it
and write it back to the file. Would be more reliable.

Cheers,
Louis

On Mon, 26 Feb 2018, 12:11 Serge Smetana,  wrote:

> Hi,
>
> I would like Elixir AST nodes to include begin and end parse character
> offsets.
> This would make it easier to write refactoring tools that modify parts of
> Elixir source files.
>
> Usecase:
>
> We have a library https://github.com/assert-value/assert_value_elixir
> that is
> able to create and update expected values in tests. For example, given the
> following:
>
> assert_value 2 + 2 == 2 + 3
>
> our code will find the location of `2 + 3` and replace it with `4`:
>
> assert_value 2 + 2 == 4
>
> Today determining the location of `2 + 3` in the source file is
> difficult.  For
> now, we use a custom-made parser which processes code char by char until
> it gets
> value matching AST:
>
> https://github.com/assert-value/assert_value_elixir/blob/master/lib/assert_value/parser.ex
> But if we had the parse offsets it would be much easier.
>
> Proposed interface:
>
> Probably need two sets of offsets, exclusive and inclusive of children.
> For
> each probably best to store beginning offset and length. Will need
> reasonable
> handling for parentheses and other tokens that do not make it into AST.
>
> Existing implementation:
>
> Elixir AST nodes do have useful info on this already. We use the "line:"
> which
> is very helpful. We don't use "column:", it did not seem useful given our
> implementation.  We may be missing something obvious here.
>
> Details:
>
> In Elixir 1.6 compiled code AST has only function line number in meta. Even
> "columns: true" in Code.string_to_quoted gives only function starting
> column
> without information about arguments.
>
> Consider the following code:
>
> Code.string_to_quoted!("(41.00 == 42.)", columns: true)
> #=> {:==, [line: 1, column: 8], [41.0, 42.0]}
>
> From the AST you don't know where to find 41.00 and 42. in a code.
> Column information does not help. AST values of 41.0 and 42.0 don't have
> information about how original values were formatted.
>
> Thanks,
> Serge
>
> --
> 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/4dbc37cc-6630-4989-acc0-c4acfd719a5b%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/CABu8xFDcupN2SX%2Bivg%2BTJ7Q0LGbxARjAgRz-uta2ck8L%3DaTmKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[elixir-core:7910] Enhancement request: parse character offsets for AST node

[Serge Smetana]

Hi,

I would like Elixir AST nodes to include begin and end parse character 
offsets.
This would make it easier to write refactoring tools that modify parts of
Elixir source files.

Usecase:

We have a library https://github.com/assert-value/assert_value_elixir that 
is
able to create and update expected values in tests. For example, given the
following:

assert_value 2 + 2 == 2 + 3

our code will find the location of `2 + 3` and replace it with `4`:

assert_value 2 + 2 == 4

Today determining the location of `2 + 3` in the source file is difficult.  
For
now, we use a custom-made parser which processes code char by char until it 
gets
value matching AST:
https://github.com/assert-value/assert_value_elixir/blob/master/lib/assert_value/parser.ex
But if we had the parse offsets it would be much easier.

Proposed interface:

Probably need two sets of offsets, exclusive and inclusive of children.  For
each probably best to store beginning offset and length. Will need 
reasonable
handling for parentheses and other tokens that do not make it into AST.

Existing implementation:

Elixir AST nodes do have useful info on this already. We use the "line:" 
which
is very helpful. We don't use "column:", it did not seem useful given our
implementation.  We may be missing something obvious here.

Details:

In Elixir 1.6 compiled code AST has only function line number in meta. Even
"columns: true" in Code.string_to_quoted gives only function starting column
without information about arguments.

Consider the following code:

Code.string_to_quoted!("(41.00 == 42.)", columns: true)
#=> {:==, [line: 1, column: 8], [41.0, 42.0]}

>From the AST you don't know where to find 41.00 and 42. in a code.
Column information does not help. AST values of 41.0 and 42.0 don't have
information about how original values were formatted.

Thanks,
Serge

-- 
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/4dbc37cc-6630-4989-acc0-c4acfd719a5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7908] Re: [Proposal] Kernel.is_module?/1

[José Valim]

> I've found that in practice both `Code.ensure_loaded` and
`Code.ensure_compiled?` are both extremely slow in practice.

Yes, modules are atoms and the only way to know if an atom is actually a
module during development is if you check if there is a .beam file on disk.

If you want a quick check if something is a module, then you can use
is_atom. There is no way we can provide a performant is_module for
development.

In production, if you do releases, then this check is faster since modules
are loaded upfront.




*José Valimwww.plataformatec.com.br
Founder and Director of R*

On Mon, Feb 26, 2018 at 12:56 AM,  wrote:

> I've found that in practice both `Code.ensure_loaded` and
> `Code.ensure_compiled?` are both extremely slow in practice. Also it is not
> very intuitive that this is what you should be reaching for when attempting
> to check what type something is. The standard pattern that has been
> established is the "is_*" in the Kernel. I think we should continue that
> pattern with modules as well.
>
> --
> 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/9f1693ba-3d92-43e3-b48f-
> b92ec5e1cf8e%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/CAGnRm4KK6E2GB1CxW-_%3DGs0NKkAv6EJ%2B3vza8jtpny-KzuptbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.