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

[OvermindDL1]

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.
>>
> --
>> 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/d1ac20e5-9198-47d1-91c4-
>> cf6d6b0e733a%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/CABu8xFC0kWY2ncPW0tm5MbyMj8WFa
> %2BD2v6bBamdB-1fyk7qu5A%40mail.gmail.com
> 

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

[Louis Pilfold]

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.
>>>
>> --
>>> 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/d1ac20e5-9198-47d1-91c4-cf6d6b0e733a%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 r

[elixir-core:7902] Proposal: Create a function on the Xref task to get a list of callers

[Matt Baker]

Hello Elixir friends. We're building "Find References" support 
 in ElixirLS (moving it 
soon to ElixirSense) so that we can find references in our editor. Right 
now we run the xref mix task and capture stdout 

 
to get the list of references.

We'd prefer to be able to get the list directly. I'm curious what folks 
think about exposing something like callers/2 

 
as a public function on the xref task (or elsewhere) that would hand back 
the list.
https://github.com/elixir-lang/elixir/blob/master/lib/mix/lib/mix/tasks/xref.ex#L268

Naively, it could be as simple as a function that includes everything 
except print_calls() and the :ok return value we see in callers/2.

What we have seems to work, so it's not a blocker, but this would 
definitely be helpful to anyone building IDE features.

If this seems like a reasonable add I would be happy to submit a PR, I 
imagine it will be a small change if folks approve of the idea.

-- 
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/6c43f8a4-39cf-4ea7-8da6-fd334e549898%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7902] Proposal: Create a function on the Xref task to get a list of callers

[José Valim]

Can you build this from the information returned by calls/2?
-- 


*José Valimwww.plataformatec.com.br
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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2B%3Dra9eSf599AB2u%3DGPnBf-1CrVX2986nzq05a%2B3D54kQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7903] Proposal: Create a function on the Xref task to get a list of callers

[Matt Baker]

Ah, perhaps! I will take a look and report back.

On Sun, Feb 25, 2018 at 12:23 PM José Valim  wrote:

> Can you build this from the information returned by calls/2?
> --
>
>
> *José Valimwww.plataformatec.com.br
> Founder and Director of R&D*
>
> --
> 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/DwbVKBH0goE/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/CAGnRm4%2B%3Dra9eSf599AB2u%3DGPnBf-1CrVX2986nzq05a%2B3D54kQ%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAMOHo4ggd%3Dp8QtSZnSf4Y0KcaRuw%3Dzm62g_WXsjQEU2jGJc-FQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7904] Proposal: Create a function on the Xref task to get a list of callers

[Matt Baker]

That did the trick, thanks for the guidance José :)

On Sun, Feb 25, 2018 at 12:26 PM, Matt Baker  wrote:

> Ah, perhaps! I will take a look and report back.
>
> On Sun, Feb 25, 2018 at 12:23 PM José Valim  wrote:
>
>> Can you build this from the information returned by calls/2?
>> --
>>
>>
>> *José Valimwww.plataformatec.com.br
>> Founder and Director of R&D*
>>
>> --
>> 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/DwbVKBH0goE/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/CAGnRm4%2B%3Dra9eSf599AB2u%
>> 3DGPnBf-1CrVX2986nzq05a%2B3D54kQ%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAMOHo4gObgk1wADujEhQz432qnUDTO305FNqHGM9fRX0cH-Emg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[tom]

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.

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

[Ben Wilson]

Can you elaborate on motivating code patterns? Every instance where I've 
wanted to determine if a specific module is around has been a compile time 
question for meta-programming purposes, and the `Code.ensure_loaded?` 
function has worked great for that.

On Sunday, February 25, 2018 at 6:56:25 PM UTC-5, t...@scalpel.com 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/7e022ca7-4129-47bd-b618-121bde6cf176%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Paul Schoenfelder]

If you are doing this at runtime and not compile-time, going through the
code server will of course be slow, as well as bottlenecked by the code
server process itself, it's a bad idea to go that route. I would want to
see the use case here, because I'm convinced there is a better way to solve
the problem you are trying to solve.

Paul

On Sun, Feb 25, 2018 at 7:03 PM Ben Wilson  wrote:

> Can you elaborate on motivating code patterns? Every instance where I've
> wanted to determine if a specific module is around has been a compile time
> question for meta-programming purposes, and the `Code.ensure_loaded?`
> function has worked great for that.
>
>
> On Sunday, February 25, 2018 at 6:56:25 PM UTC-5, t...@scalpel.com 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/7e022ca7-4129-47bd-b618-121bde6cf176%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/CAK%3D%2B-Tv6JEwRhMMUmYWUQT4%2BTzUxvYG7DiaVsUz_XORg1Nxd2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.