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-core+unsubscr...@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.
