thank you for your answer José, I can look into how we can add new kinds (I will need help with defining how to deal with conflicting kinds). I think the defguard approach is reasonable, but I thought it was ditched for some reason.
What we could do is create a defkind macro that uses defguard, but creates kinds only (since defguard can create any kind of guard). Is there any propototype already, besides https://gist.github.com/christhekeele/8284977 and what do you think about his approach? thank you. On Thu, 11 Aug 2016 17:46:52 +0200 José Valim <jose.va...@plataformatec.com.br> wrote: > Thank you Eksperimental for a great and detailed proposal with working > implementation. > > My biggest concern is that the "kinds" are not extensible. We are > replacing something that is extensible (defining functions) with an > atom-tuple based lookup that is not. Even if guards are somewhat > limited, someone could implement is_mfa/1, is_even/1 and is_odd/1 in > their codebases today. > > Therefore, in your proposal, how could someone add new kinds? If two > libraries define conflicting kinds, how can we resolve such > conflicts? One option is to make {:kind, 1} to always expand to > is_kind(term, 1) but, if that is the case, I would prefer to add > defguard that makes it simpler to define guards as regular macros > without the kind indirection. I believe we had a defguard proposal > flying around at some point. > > This proposal also blurries the line between guards and @specs. I > would love to have an unified view but I am not sure how such would > eventually work and I am worried that any step taken now may make it > harder to move to another direction in the future. > > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > On Thu, Aug 11, 2016 at 5:30 PM, eksperimental > <eksperimen...@autistici.org> wrote: > > > Hi everyone in this list, > > > > I hope it has a good reception among the community, since it has the > > potential to change the way we write functions guards in a very > > positive and more natural way. > > > > Guards clauses are a key feature in Elixir. Researching > > how to make it easier for developers to define guards, has led me to > > two enhancement proposal. This is the first one, which will allow > > developers to write guards, guard safe macros and other clauses in a > > more natural and succinct way. > > > > All the following macros are allowed in guards: > > - `is_kind(term, kind)` determines if a given `term` is of a certain > > `kind`. > > - `term is kinds` determines if `term` is each kind in `kinds`. > > - `term is_not kinds` determines if `term` is not of any of the > > `kinds`. > > - `term is_any kinds` determines if `term` is of any of the `kinds`. > > - `terms are kinds` determines if every term in list `terms` is of > > every kind in `kinds`. > > - `terms are_not kinds` determines if every item in list `terms` is > > not of `kind`. > > - `terms are_any kinds` determines if every term in list `terms` is > > not of any of the `kinds`. > > > > Allowing us to write functions guards as regular code, that > > otherwise it would take a really long lines of code: > > > > def check(letter) when letter is :char, do: true > > > > iex> [100, 200] are [:even, {:>=, 100}] > > true > > > > write expressions in a more natural way: > > iex> term is_not nil > > > > as opposed to > > iex> not is_nil(term) > > > > For a list of all supported kinds, see the list: > > https://gist.github.com/eksperimental/a6df4348e9675109e49ccf > > 4e34101bfe#list-of-supported-kinds-by-is_kind2 > > > > Here's the proposal: > > https://gist.github.com/eksperimental/a6df4348e9675109e49ccf4e34101bfe > > > > and here the its full implementation: > > https://github.com/eksperimental/elixir/tree/is-kind > > > > Looking forwards to hear your opinions > > > > -- > > 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/ms > > gid/elixir-lang-core/20160811223043.7a17eb02.eksperimental%40autistici.org . > > 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/20160813002326.1173216e.eksperimental%40autistici.org. For more options, visit https://groups.google.com/d/optout.
