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/74d93cd4-daca-4ac7-acf8-dedc4206fdb4n%40googlegroups.com.
