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/CAGnRm4LtsnHP-WWCh-gpfrgV6fcR-c9q6pMxksunWtYWMB5brw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
