Unfortunately general comparison requires multiple dispatch, because it is
supposed to work regardless of the argument order.
For example, imagine that we provide a Comparable protocol and we implement
it in Elixir for Integer and Float. Now, the Decimal library will also
implement Comparable, and it also wants to work with Integer and Float. So
we can handle:
Comparable.compare(decimal, integer)
Comparable.compare(decimal, float)
However, we can't handle:
Comparable.compare(float, decimal)
Comparable.compare(integer, decimal)
Because Elixir knows nothing about Decimal and I think not having that work
breaks comparison in weird and surprising ways.
Now extend this to everything: you want it so Nx tensors can compare to
integers and floats, as well as decimals. Then you will see a protocol
solution indeed does not scale (code-wise).
What languages (both static and dynamic) typically do in cases without
multiple dispatch is to provide a protocol for comparison.
NumberComparable, DecimalComparable, TimeComparable, etc.
On Tue, Nov 1, 2022 at 2:09 PM Cliff <notcliffwilli...@gmail.com> wrote:
> Okay, I'm totally in love with this idea :)
>
> *iex(1)>*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *defprotocol Comparable do @spec compare(t, t) :: :lt | :eq | :gt def
> compare(a, b)enddefimpl Comparable, for: Integer do def compare(a, b) do
> cond do a < b -> :lt a == b -> :eq a > b -> :gt end
> endenddefimpl Comparable, for: DateTime do def compare(a, b) do
> DateTime.compare(a, b) endenddefmodule Foo do def a >= b do
> Comparable.compare(a, b) != :lt endendimport Kernel, except: [>=: 2]import
> Foo*
>
> It's magic!
>
> *iex(2)>* 2 >= 1
> *true*
> *iex(3)>* DateTime.add(DateTime.utc_now(), 10, :hour) >=
> DateTime.utc_now()
> *true*
> On Tuesday, November 1, 2022 at 8:55:14 AM UTC-4 Cliff wrote:
>
>> Actually, using something like a *Comparable* protocol (as Jose
>> mentioned) would do this using already-existing language features.
>>
>> On Tuesday, November 1, 2022 at 8:46:08 AM UTC-4 Cliff wrote:
>>
>>> 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/7d7af1d6-bff7-4fbe-a3c4-0da74ac104d9n%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/7d7af1d6-bff7-4fbe-a3c4-0da74ac104d9n%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/CAGnRm4JmCeCXGHGmHgO0y3bK3P5z1YcoDuZnb3e_%3DtOzZxd24w%40mail.gmail.com.
