"is_positive_integer IO.inspect(1)" in the macro you have posted will
inspect the value twice when used in the function body.
"is_positive_integer send(self(), 1)" would send the message to self twice
and so on.
*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D
On Fri, Aug 12, 2016 at 10:22 PM, Paul Schoenfelder <
paulschoenfel...@gmail.com> wrote:
> Hey José, could you give an example of what you mean? At least with those
> guards, using them in function bodies appears to work just fine, is it
> because they are working on simple types (i.e. integer, tuple)? If it does
> fall down in the general case, I can definitely see where that would make
> it a non-workable solution, in the case of Timex I'm only using those
> macros in function guards anyway, but some tests with those macros locally
> seems to work as expected whether in a function guard or used in the body
> like a function.
>
> Paul
>
> On Fri, Aug 12, 2016 at 3:22 PM, eksperimental <
> eksperimen...@autistici.org> wrote:
>
>> the Comparison group of kinds was the last group and I just included just
>> to see how much i could
>> push guard,
>>
>> But the rest of the groups are less controversial.
>>
>> - Basic and built-in types
>> - Additional: Derived from is_* functions
>> - Additional: Literal numbers
>>
>> and maybe it is arguable if we need them all of them,
>> - Additional: Convenience
>>
>> Would it be possible to have the best of both worlds here?
>> Allow users to define their own guards/kinds, and be able to call them
>> from is/are functions, and
>> offering a default set of kinds/guards like the ones listed above (or
>> whatever we agree are the
>> minimum needed to be supported by the language).
>>
>> defmodule DateTime
>>
>> defkind second(seconds) when seconds >= 0 and seconds <= 60
>>
>> def new(..., seconds) when seconds is :second
>>
>> end
>>
>> The benefit of are* functions is that it reduces the amount in a
>> significant way when you have
>> several items on the left and several kinds on the right hand side.
>>
>> also having a defined list of default kinds, helps us to translate
>> directly from the typespecs into
>> guard definitions.
>>
>> On Fri, 12 Aug 2016 20:24:22 +0200
>> José Valim <jose.va...@plataformatec.com.br> wrote:
>>
>> > >
>> > > 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).
>> > >
>> >
>> > I think the concern runs a little bit deeper: if we have defkind, that
>> is
>> > based on defguard, are they then like any other macro? Would we also
>> manage
>> > importing and conflicts with import? If so, why don't we use them like
>> any
>> > other macro?
>> >
>> > When reading your proposal, I effectively broke it two parts:
>> >
>> > 1. A huge collection of kinds, which could be implemented as macros.
>> > Imagine if we had is_mfa/1, is_list/2 and so on in the stdlib or on a
>> > Guards module.
>> >
>> > 2. A set of operators that easily apply a set of kinds (or macros) on
>> the
>> > rhs to the lhs.
>> >
>> > Once we break it apart, I have the following feedback:
>> >
>> > 1. Instead of having a large collection of guards in the stdlib maybe we
>> > should make it easier to define your own guards since most times you can
>> > give it better names that are specific to your domain
>> >
>> > 2. What is the benefit of using "is/are" instead of multiple "and/or"
>> > calls? I am aware the former is more succinct but remember that if we
>> have
>> > multiple and/or calls, then we can always create a new guard with
>> defguard
>> >
>> > In other words, instead of having a general solution with a bunch of
>> guards
>> > in the stdlib alongside some pre-defined combinations, I would prefer to
>> > have a composable solution that is built from small blocks because folks
>> > can extend it to their domain without forcing Elixir to add more kinds.
>> >
>> > Let me try to be more concrete. With the proposal above, I'd be tempted
>> to
>> > write:
>> >
>> > defmodule DateTime
>> > def new(..., seconds) when seconds is [{:gte, 0}, {:lte, 60}] do
>> >
>> >
>> > But the best solution would most likely be:
>> >
>> > defmoduel DateTime
>> >
>> > defguard is_seconds(seconds) when seconds >= 0 and seconds <= 60
>> >
>> > def new(..., seconds) when is_seconds(seconds)
>> >
>> > end
>> >
>> >
>> > Finally, I just want to say that, although I am not convinced on the
>> "kind"
>> > mechanism, I love this proposal because it is asking the right questions
>> > and it makes me realize I could be writing better code. So thank you for
>> > that!
>> >
>>
>> --
>> 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/20160813022209.5a991c28.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/CAK%3D%2B-TviuNP1gAiN6tR0C%2BKAFXj_
> uCXxzcYnib5Dv7FdNFwujw%40mail.gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-TviuNP1gAiN6tR0C%2BKAFXj_uCXxzcYnib5Dv7FdNFwujw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/CAGnRm4J2DJN41Z_Twe5VpQ4p6nx02N968OPrKyp0MUWO4p%3D%3DDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
