Would it be possible to allow different modules to define multiple clauses
of the same function as long as they don't overlap? i.e. DateTime could
define
*defmodule DateTime do*
* def %DateTime{ ... } >= %DateTime{ ... } do ... endend*
So that if you *import DateTime, only: [:>=]*, a call to >= using DateTime
structs would use DateTime.>=, and all other calls would match the clause
for Kernel.>=?
On Monday, October 31, 2022 at 6:50:19 PM UTC-4 Billy Lanchantin wrote:
> FWIW, I think a macro approach that takes a single argument and allows
> chained comparisons covers a lot of the cases being discussed here.
>
> Consider something like:
>
> # imports a compare?/1 macro
> use CompareChain, for: DateTime
>
> def between?(left, middle, right) do
> compare?(left <= middle < right)
> end
>
> The code reads well since you don't have the module name getting in the
> way. And it covers the annoying inclusive/exclusive issue quite nicely I
> think.
>
> It's also convenient because I often find myself combining the results of
> comparisons (Ben provided some good examples). Being able to chain the
> operators within the macro helps avoids much of that verbose code. For
> instance, even with DateTime.before?/3 and DateTime.after?/3, you'd have
> to render my between?/3 as something like:
>
> def between?(left, middle, right) do
> DateTime.before?(left, middle, inclusive: true) and
> DateTime.after?(right, middle)
> end
> On Monday, October 31, 2022 at 6:18:09 PM UTC-4 halos...@gmail.com wrote:
>
>> I would *personally* appreciate an inclusive option from the start, as
>> sometimes the `b` value is pulled from a database and to make the `before?`
>> work the way `<=` would, I’d have to *add* a millisecond (or day or…) and
>> for `after?` I’d have to *subtract*.
>>
>> -a
>>
>> On Mon, Oct 31, 2022 at 5:26 PM José Valim <jose....@dashbit.co> wrote:
>>
>>> Making DateTime.compare?(left, :<=, right) resemble left <= right can be
>>> a win but i think it can also cause confusion in that "why not use left <=
>>> right in the first place"? And once we import, it makes me wonder why it
>>> isn't a protocol so we can compare anything?
>>>
>>> I am not saying we shouldn't tackle those problems... but those are
>>> likely to take longer discussions.
>>>
>>> At the same time, I don't feel we have to pick one option or the other.
>>> So I would start with DateTime.before?/2 and DateTime.after?/2 for now,
>>> which is definitely an improvement over the current code and may as well
>>> elegantly solve the problem in the long term. If not, it is no problem to
>>> restart the discussion.
>>>
>>> So a PR for before?/2 and after?/2 (no inclusive for now) on all 4
>>> modules is welcome. :)
>>>
>>>
>>>
>>> On Mon, Oct 31, 2022 at 10:14 PM Ben Wilson <benwil...@gmail.com> wrote:
>>>
>>>> Making < and <= work in general for DateTime has been discussed and
>>>> isn't feasible. The macro answer I kinda love.
>>>>
>>>> On Monday, October 31, 2022 at 3:42:16 PM UTC-4 m...@achempion.com
>>>> wrote:
>>>>
>>>>> Is it possible to modify language in a way to make >,<, = work for
>>>>> dates?
>>>>>
>>>>> The datetime's struct has known values
>>>>> <https://github.com/elixir-lang/elixir/blob/v1.14.1/lib/elixir/lib/calendar/datetime.ex#L110-L123>
>>>>> which
>>>>> can be pattern matched against and struct comparison, in general, is not
>>>>> used that match, so it shouldn't mess up with already written code (maybe
>>>>> we even fix couple bugs as using >,<,= to compare dates are relatively
>>>>> common first bug for new elixir developers).
>>>>>
>>>>> If we can ducktype struct with such attributes and use a regular
>>>>> DateTime.compate/2 to compare it in Kernel.>/2 function and friends.
>>>>>
>>>>> On 31 Oct 2022, at 19:54, Cliff <notcliff...@gmail.com> wrote:
>>>>>
>>>>> I did some more playing around and created this macro:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *defmodule Foo do defmacro compare_with(comparison, module) do
>>>>> {op, _env, [a, b]} = comparison cmp_result = quote do
>>>>> unquote(module).compare(unquote(a), unquote(b)) end case op do
>>>>> :> -> {:==, [], [cmp_result, :gt]} :< -> {:==, [],
>>>>> [cmp_result, :lt]} :>= -> {:!=, [], [cmp_result, :lt]}
>>>>> :<=
>>>>> -> {:!=, [], [cmp_result, :gt]} end endend*
>>>>>
>>>>> I don't think it is actually a good solution to this issue, but just
>>>>> wanted to share the idea.
>>>>>
>>>>> *(a >= b) |> compare_with(DateTime)*
>>>>>
>>>>> On Monday, October 31, 2022 at 2:46:09 PM UTC-4 benwil...@gmail.com
>>>>> wrote:
>>>>>
>>>>> > DateTime.compare(a, :<, b) would get my vote of the alternative
>>>>>> proposals but I think it doesn't move much the needle in comparison to
>>>>>> DateTime.compare.
>>>>>>
>>>>>> To me this is a pretty big difference difference, because with an
>>>>>> `import` it does 2 things:
>>>>>>
>>>>>> 1) Eliminates the existence of an irrelevant, boilerplate operator ==
>>>>>> 2) positions the 2 values you care about correctly with respect to
>>>>>> the relevant operator
>>>>>>
>>>>>> When you have
>>>>>>
>>>>>> DateTime.compare(a, b) == :lt
>>>>>>
>>>>>> it's like RPN, you have to hold a and b in your head, remember their
>>>>>> order, then skip past the `==` since it doesn't matter, and finally you
>>>>>> get
>>>>>> to see your comparison. When discussing this in complex contexts the
>>>>>> need
>>>>>> to try to distinguish about whether you're talking about what the
>>>>>> _function
>>>>>> call is equal to_ from whether the values themselves are equal to is
>>>>>> actually a pretty big deal. There are basically 4 characters with
>>>>>> semantic
>>>>>> value, and there rest are boilerplate. When you have a bunch of these
>>>>>> all
>>>>>> next to each other (like when building up complex range helpers)
>>>>>> https://gist.github.com/benwilson512/456735775028c2da5bd38572d25b7813
>>>>>> it's just a ton of data to filter out.
>>>>>>
>>>>>> If you could `import DateTime, compare?: 3` this could be
>>>>>>
>>>>>> compare?(a, :<, b)
>>>>>> compare?(a, :<=, b)
>>>>>>
>>>>>> On Monday, October 31, 2022 at 2:02:03 PM UTC-4 Cliff wrote:
>>>>>>
>>>>> > in Elixir the subject is always the first argument
>>>>>>>
>>>>>>> Ah, that clears it up for me, I hadn't yet realized that symmetry in
>>>>>>> the APIs. I like the before?/after? functions now.
>>>>>>>
>>>>>>> On Monday, October 31, 2022 at 1:16:52 PM UTC-4 José Valim wrote:
>>>>>>>
>>>>>> I am not worried about the argument order because in Elixir the
>>>>>>>> subject is always the first argument. So it is always "is date1 before
>>>>>>>> date2?". I like the :inclusive option if the need ever arises.
>>>>>>>>
>>>>>>>> DateTime.compare(a, :<, b) would get my vote of the alternative
>>>>>>>> proposals but I think it doesn't move much the needle in comparison to
>>>>>>>> DateTime.compare.
>>>>>>>>
>>>>>>>> On Mon, Oct 31, 2022 at 5:44 PM Cliff <notcliff...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>> I would prefer the atoms *:before*, and *:after* rather than
>>>>>>>>> :gt/:greater_than/etc. Since we're already solving the problem of
>>>>>>>>> operator/argument ordering, why not remove the final mental barrier
>>>>>>>>> of
>>>>>>>>> reasoning about whether a time being "greater than" another time
>>>>>>>>> means that
>>>>>>>>> it is before or after? *foo(a, :gt, b)* still requires a second
>>>>>>>>> thought ("Is a bigger time earlier or later?"), whereas if I read
>>>>>>>>> code that
>>>>>>>>> said *foo(a, :before, b)* I would feel confident in my
>>>>>>>>> understanding after only the first read.
>>>>>>>>>
>>>>>>>>> On Monday, October 31, 2022 at 12:35:05 PM UTC-4 lui...@gmail.com
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>> I also prefer something like *DateTime.compare(a, operator, b)*.
>>>>>>>>>>
>>>>>>>>>> Operators don't need to be *cryptic* like *:eq*, *:gt*, *:lte*,
>>>>>>>>>> etc., we can use the same comparison operators we already are used
>>>>>>>>>> to:
>>>>>>>>>>
>>>>>>>>>> *DateTime.compare(a, :<, b)*
>>>>>>>>>> *DateTime.compare(a, :==, b)*
>>>>>>>>>> *DateTime.compare(a, :>=, b)*
>>>>>>>>>>
>>>>>>>>>> It's clear and much less verbose than the Ecto's (which was a
>>>>>>>>>> great suggestion, by the way).
>>>>>>>>>>
>>>>>>>>>> On Monday, October 31, 2022 at 5:23:54 PM UTC+1 and...@dryga.com
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>> Hey guys, as an idea why don't we reuse atoms from Ecto:
>>>>>>>>>>>
>>>>>>>>>>> - :less_than
>>>>>>>>>>> - :greater_than
>>>>>>>>>>> - :less_than_or_equal_to
>>>>>>>>>>> - :greater_than_or_equal_to
>>>>>>>>>>> - :equal_to
>>>>>>>>>>> - :not_equal_to
>>>>>>>>>>>
>>>>>>>>>>> I feel like they are fairly common nowadays and even though it's
>>>>>>>>>>> more to type make it easier to understand when you want an
>>>>>>>>>>> inclusive
>>>>>>>>>>> comparison.
>>>>>>>>>>>
>>>>>>>>>>> We can later make it part of all modules that have `compare/2`
>>>>>>>>>>> (Date, DateTime, Time, Version, etc).
>>>>>>>>>>>
>>>>>>>>>>> On Monday, October 31, 2022 at 10:10:09 AM UTC-6 Cliff wrote:
>>>>>>>>>>>
>>>>>>>>>> I prefer the form *DateTime.is <http://DateTime.is>(a, operator,
>>>>>>>>>>>> b)*, but I agree with others that it would need a more
>>>>>>>>>>>> sensible name than "is".
>>>>>>>>>>>>
>>>>>>>>>>>> Regarding the form *DateTime.before?(a, b)*, I could still see
>>>>>>>>>>>> myself getting confused by argument order. *before?(a, b)* might
>>>>>>>>>>>> be read as "before A happened, B happened", rather than the
>>>>>>>>>>>> intended "A
>>>>>>>>>>>> happened before B". the *is(a, :before, b)* form, however, is
>>>>>>>>>>>> read exactly how it would be spoken.
>>>>>>>>>>>>
>>>>>>>>>>>> Regarding comparison inclusivity, another possibility is a
>>>>>>>>>>>> keyword option: *DateTime.before?(a, b, inclusive: true)*
>>>>>>>>>>>>
>>>>>>>>>>>> On Monday, October 31, 2022 at 3:45:15 AM UTC-4
>>>>>>>>>>>> simonmc...@gmail.com wrote:
>>>>>>>>>>>>
>>>>>>>>>>> DateTime.before?(a, b) is much nicer than DateTime.compare(a, b)
>>>>>>>>>>>>> == :lt. It doesn't completely remove the argument order issue
>>>>>>>>>>>>> but I reckon
>>>>>>>>>>>>> it would resolve it for me. I run DateTime.compare(a, b) in iex
>>>>>>>>>>>>> every time
>>>>>>>>>>>>> I use the function because I'm terribly forgetful and paranoid.
>>>>>>>>>>>>> I would
>>>>>>>>>>>>> prefer DateTime.eq?/lt?/le?/gt?/ge? instead of
>>>>>>>>>>>>> before?/after?/on_or_before?/on_or_after? which is shorter,
>>>>>>>>>>>>> matches
>>>>>>>>>>>>> compare/2 and might allow the le/ge equivalents to sneak through.
>>>>>>>>>>>>> I think
>>>>>>>>>>>>> it would be a shame to leave out le and ge.
>>>>>>>>>>>>>
>>>>>>>>>>>>> DateTime.is?/compare?(a, :lt, b) is a whole lot less
>>>>>>>>>>>>> ambiguous to me. It reads how you would write it in maths or
>>>>>>>>>>>>> spoken
>>>>>>>>>>>>> language.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Monday, 31 October 2022 at 5:08:35 pm UTC+10
>>>>>>>>>>>>> zachary....@gmail.com wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>> I wonder how much of the issue is the Api and how much of the
>>>>>>>>>>>>>> issue is just the docs? I.e its not a given that all arguments
>>>>>>>>>>>>>> in every
>>>>>>>>>>>>>> position always make sense, but we typically rely on things like
>>>>>>>>>>>>>> elixir_ls
>>>>>>>>>>>>>> to help us when the answer isn't obvious.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could we perhaps just improve the docs in some way? i.e
>>>>>>>>>>>>>> update the specs to say `datetime :: Calendar.datetime(),
>>>>>>>>>>>>>> compares_to ::
>>>>>>>>>>>>>> Calendar.datetime()`, and have the args say `compare(datetime,
>>>>>>>>>>>>>> compares_to)` and have part of the first line of text say
>>>>>>>>>>>>>> something a bit
>>>>>>>>>>>>>> more informative?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Oct 31, 2022 at 3:02 AM, Jon Rowe <
>>>>>>>>>>>>>> ma...@jonrowe.co.uk> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not sure the name is right, but I like
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> DateTime.is?(a <http://datetime.is/?(a>, operator, b), when
>>>>>>>>>>>>>>> operator :lt | :le | :eq | :ge | :gt, which would capture the
>>>>>>>>>>>>>>> :le and :ge
>>>>>>>>>>>>>>> options.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As a usage api, we could actually have `compare?/3`
>>>>>>>>>>>>>>> especially as the name doesn't overlap with `compare/2` which
>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>> hopefully alleviate anyones concerns about the return type
>>>>>>>>>>>>>>> changing
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, 31 Oct 2022, at 6:23 AM, José Valim wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My thought process is that a simple to use API should be the
>>>>>>>>>>>>>>> focus, because we already have a complete API in
>>>>>>>>>>>>>>> Date.compare/2 <http://date.compare/2> and friends.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Oct 31, 2022 at 02:16 Simon McConnell <
>>>>>>>>>>>>>>> simonmc...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> would we want on_or_after? and on_or_before? as well then?
>>>>>>>>>>>>>>> Or something like DateTime.is?(a <http://datetime.is/?(a>,
>>>>>>>>>>>>>>> operator, b), when operator :lt | :le | :eq | :ge | :gt, which
>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>> capture the :le and :ge options.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Monday, 31 October 2022 at 7:26:42 am UTC+10 José Valim
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A PR that adds before?/after? to Time, Date, NaiveDateTime,
>>>>>>>>>>>>>>> and DateTime is welcome!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Oct 30, 2022 at 6:46 PM Cliff <notcliff...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I did a bit of research. Many other languages use some form
>>>>>>>>>>>>>>> of operator overloading to do datetime comparison. The ones
>>>>>>>>>>>>>>> that do
>>>>>>>>>>>>>>> something different:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Java has LocalDateTime.compareTo(other)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/LocalDateTime.html#compareTo(java.time.chrono.ChronoLocalDateTime)>,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> returning an integer representing gt/lt/eq. There is also
>>>>>>>>>>>>>>> LocalDateTime.isBefore(other)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/LocalDateTime.html#isBefore(java.time.chrono.ChronoLocalDateTime)>,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> LocalDateTime.isAfter(other), and
>>>>>>>>>>>>>>> LocalDateTime.isEqual(other). The
>>>>>>>>>>>>>>> LocalDateTime.is <http://localdatetime.is/>{Before,
>>>>>>>>>>>>>>> After} methods are non-inclusive (<, >) comparisons. They
>>>>>>>>>>>>>>> are instance
>>>>>>>>>>>>>>> methods, so usage is like `myTime1.isBefore(myTime2)`
>>>>>>>>>>>>>>> - OCaml's "calendar" library provides a Date.compare
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://ocaml.org/p/calendar/3.0.0/doc/CalendarLib/Date/index.html#val-compare>
>>>>>>>>>>>>>>> function that returns an integer representing gt/lt/eq
>>>>>>>>>>>>>>> (for use in OCaml's List.sort function, which sorts a list
>>>>>>>>>>>>>>> according to the
>>>>>>>>>>>>>>> provided comparison function). It also provides Date.>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://ocaml.org/p/calendar/3.0.0/doc/CalendarLib/Date/index.html#val-(%3E)>,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> and Date.>=
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://ocaml.org/p/calendar/3.0.0/doc/CalendarLib/Date/index.html#val-(%3E=)>,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> etc. Worth noting is that OCaml allows you to do
>>>>>>>>>>>>>>> expression-level module
>>>>>>>>>>>>>>> imports, like *Date.(my_t1 > my_t2)* to use Date's *>*
>>>>>>>>>>>>>>> function
>>>>>>>>>>>>>>> in the parenthesized expression without needing to *open
>>>>>>>>>>>>>>> Date* in the entire scope ("open" is OCaml's "import") -
>>>>>>>>>>>>>>> this could potentially be possible in Elixir using a macro?
>>>>>>>>>>>>>>> - Golang: t1.After(t2)
>>>>>>>>>>>>>>> <https://pkg.go.dev/time#Time.After>, t1.Before(t2),
>>>>>>>>>>>>>>> t1.Equal(t2). Non-inclusive (> and <).
>>>>>>>>>>>>>>> - Clojure clj-time library: (after? t1 t2)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://clj-time.github.io/clj-time/doc/clj-time.core.html#var-after.3F>
>>>>>>>>>>>>>>> , (before? t1 t2)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://clj-time.github.io/clj-time/doc/clj-time.core.html#var-before.3F>,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> and (equal? t1 t2)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://clj-time.github.io/clj-time/doc/clj-time.core.html#var-equal.3F>.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> IMO the argument order is still confusing in these.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sunday, October 30, 2022 at 3:15:14 AM UTC-4 José Valim
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am definitely in favor of clearer APIs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However, it would probably be best to explore how different
>>>>>>>>>>>>>>> libraries in different languages tackle this. Can you please
>>>>>>>>>>>>>>> explore this?
>>>>>>>>>>>>>>> In particular, I am curious to know if before/after mean "<"
>>>>>>>>>>>>>>> and ">"
>>>>>>>>>>>>>>> respectively or if they mean "<=" and "=>" (I assume the
>>>>>>>>>>>>>>> former). And also
>>>>>>>>>>>>>>> if some libraries feel compelled to expose functions such as
>>>>>>>>>>>>>>> "after_or_equal" or if users would have to write
>>>>>>>>>>>>>>> Date.equal?(date1, date2)
>>>>>>>>>>>>>>> or Date.earlier?(date1, date2), which would end-up doing the
>>>>>>>>>>>>>>> double of
>>>>>>>>>>>>>>> conversions.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> 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/fcd07389-c6a0-497d-9c09-7f1eacf620c6n%40googlegroups.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/fcd07389-c6a0-497d-9c09-7f1eacf620c6n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> 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/e6c55604-c3ea-464c-908c-5a6092f4d8edn%40googlegroups.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/e6c55604-c3ea-464c-908c-5a6092f4d8edn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> 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/CAGnRm4%2ByT9jA7uqGX0Cyapgfx0AjW%2BU_d4Ai-NQ6vD9UsEb2uQ%40mail.gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2ByT9jA7uqGX0Cyapgfx0AjW%2BU_d4Ai-NQ6vD9UsEb2uQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> 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/2e821e87-6ee0-4702-b69f-e2616b61b1dd%40app.fastmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/2e821e87-6ee0-4702-b69f-e2616b61b1dd%40app.fastmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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/7435b979-d0eb-4726-aa65-a94ada53d320n%40googlegroups.com
>>>>>>>>>
>>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/7435b979-d0eb-4726-aa65-a94ada53d320n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>
>>>>> --
>>>>> 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/2ca24f84-0a77-4dcc-8917-83ef18bba16an%40googlegroups.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/2ca24f84-0a77-4dcc-8917-83ef18bba16an%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>>
>>>>> --
>>>> 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/89619070-2b42-409a-bdeb-1259375f7f14n%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/elixir-lang-core/89619070-2b42-409a-bdeb-1259375f7f14n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>>> 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/CAGnRm4%2BPces0tbWQeZr-iuC%2BZWEyugRJ_9Op8d6oKZ6MmsQAkQ%40mail.gmail.com
>>>
>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BPces0tbWQeZr-iuC%2BZWEyugRJ_9Op8d6oKZ6MmsQAkQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> --
>> Austin Ziegler • halos...@gmail.com • aus...@halostatue.ca
>> http://www.halostatue.ca/ • http://twitter.com/halostatue
>>
>
--
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/79e76d60-d08c-4253-832d-7ea99a37eeedn%40googlegroups.com.
