Re: [elixir-core:11752] [Proposal] Add `shift/2-3` to calendar types

[Kip Cole]

> but what you said makes sense on paper

Thats been an issue my whole life. Works well on paper, but …..  :-)

Will work up a PR ASAP.

> On 9 May 2024, at 12:54 PM, José Valim  wrote:
> 
> Hi Kip, please send a PR. I think this will be easier to see in code but what 
> you said makes sense on paper. :)
> 
> On Thu, May 9, 2024 at 02:19 Kip  <mailto:kipco...@gmail.com>> wrote:
>> I'm just now implementing the new callbacks for `ex_cldr_calendars` and in 
>> reviewing the implementation for `Calendar.ISO` is strikes me that the whole 
>> implementation, except for one line (see below) depends only on other 
>> calendar callbacks. And therefore could be moved into the `Calendar` module 
>> and used as an implementation for any calendar that implements `Calendar` 
>> behaviour.
>> 
>> This line 
>> <https://github.com/elixir-lang/elixir/blob/main/lib/elixir/lib/calendar/iso.ex#L1564>
>>  would need to change to use `calendar.months_in_year/1` and a few other 
>> calls would need to change to be calendar-referenced to. Moving the code 
>> might also allow centralising the options handling and exceptions - it's a 
>> little unusual for me to see callbacks handling the options validation 
>> rather than the public API.
>> 
>> I am more than happy to submit a PR for this very small refactor (thanks to 
>> the very clean implementation) if this idea is considered to have merit.
>> 
>> 
>> On Saturday, March 9, 2024 at 1:42:34 AM UTC+11 br...@grox.io 
>> <mailto:br...@grox.io> wrote:
>>> The biggest question is if we consider the fields in Duration a unit or 
>>> not. If they are units, then the most consistent choice is to keep them 
>>> singular, to mirror System.time_unit and friends.
>>> 
>>> 
>>> This is the API I prefer: units. IMHO, it is more important to keep 
>>> consistency with Elixir libraries. 
>>> 
>>> -bt
>>> 
>>> On Thu, Mar 7, 2024 at 11:02 PM José Valim > wrote:
>>>> It is worth noting that Date and friends in Elixir require a calendar 
>>>> field, which is not present in Duration, and therefore Duration won't be 
>>>> usable as Date (and friends).
>>>> 
>>>> The biggest question is if we consider the fields in Duration a unit or 
>>>> not. If they are units, then the most consistent choice is to keep them 
>>>> singular, to mirror System.time_unit and friends.
>>>> 
>>>> On Fri, Mar 8, 2024 at 4:55 AM Kip Cole > wrote:
>>>>> In my head, a Date.t is semantically a duration. So it’s completely valid 
>>>>> to pass it as a duration to Date.shift as I see it. Which argues for 
>>>>> singular names.
>>>>> 
>>>>> This conversation is a bit like “is a date a point in time or an 
>>>>> interval”. And the answer is yes, depending.
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On 8 Mar 2024, at 14:39, Sabiwara Yukichi > wrote:
>>>>>> 
>>>>>> 
>>>>>> I'm personally leaning more towards the plural, because it feels 
>>>>>> semantically more correct to treat a point of time and a duration as 
>>>>>> separate.
>>>>>> 
>>>>>> d.year means the same thing if d is either a date or a datetime, but for 
>>>>>> a duration calling it d.years emphasizes the difference.
>>>>>> 
>>>>>> It could perhaps help catch errors as well, both for the human and the 
>>>>>> compiler.
>>>>>> One (arguably contrived) example would be structurally typed code which 
>>>>>> doesn't enforce any type in particular but uses the dot access or 
>>>>>> partial pattern matches like %{year: ..., month: ...} in order to 
>>>>>> support both dates or datetimes. Passing in a duration wouldn't make 
>>>>>> sense semantically, having different names would make it fail properly.
>>>>>> 
>>>>>> I also agree with other reasons mentioned, the known standard one 
>>>>>> especially.
>>>>>> 
>>>>>> Le jeu. 7 mars 2024 à 16:07, 'Theo Fiedler' via elixir-lang-core 
>>>>>> > a écrit :
>>>>>>> Right, it would make using a Duration in combination with the `add/2-3` 
>>>>>>> functions much harder than it needs to be. So far all time units in 
>>>>>>> Elixir are singular, an

Re: [elixir-core:11751] [Proposal] Add `shift/2-3` to calendar types

[Kip]

I'm just now implementing the new callbacks for `ex_cldr_calendars` and in 
reviewing the implementation for `Calendar.ISO` is strikes me that the 
whole implementation, except for one line (see below) depends only on other 
calendar callbacks. And therefore could be moved into the `Calendar` module 
and used as an implementation for any calendar that implements `Calendar` 
behaviour.

This line 
<https://github.com/elixir-lang/elixir/blob/main/lib/elixir/lib/calendar/iso.ex#L1564>
 would 
need to change to use `calendar.months_in_year/1` and a few other calls 
would need to change to be calendar-referenced to. Moving the code might 
also allow centralising the options handling and exceptions - it's a little 
unusual for me to see callbacks handling the options validation rather than 
the public API.

I am more than happy to submit a PR for this very small refactor (thanks to 
the very clean implementation) if this idea is considered to have merit.


On Saturday, March 9, 2024 at 1:42:34 AM UTC+11 br...@grox.io wrote:

> The biggest question is if we consider the fields in Duration a unit or 
> not. If they are units, then the most consistent choice is to keep them 
> singular, to mirror System.time_unit and friends.
>
>
> This is the API I prefer: units. IMHO, it is more important to keep 
> consistency with Elixir libraries. 
>
> -bt
>
> On Thu, Mar 7, 2024 at 11:02 PM José Valim  wrote:
>
>> It is worth noting that Date and friends in Elixir require a calendar 
>> field, which is not present in Duration, and therefore Duration won't be 
>> usable as Date (and friends).
>>
>> The biggest question is if we consider the fields in Duration a unit or 
>> not. If they are units, then the most consistent choice is to keep them 
>> singular, to mirror System.time_unit and friends.
>>
>> On Fri, Mar 8, 2024 at 4:55 AM Kip Cole  wrote:
>>
>>> In my head, a Date.t is semantically a duration. So it’s completely 
>>> valid to pass it as a duration to Date.shift as I see it. Which argues for 
>>> singular names.
>>>
>>> This conversation is a bit like “is a date a point in time or an 
>>> interval”. And the answer is yes, depending.
>>>
>>> Sent from my iPhone
>>>
>>> On 8 Mar 2024, at 14:39, Sabiwara Yukichi  wrote:
>>>
>>> 
>>> I'm personally leaning more towards the plural, because it feels 
>>> semantically more correct to treat a point of time and a duration as 
>>> separate.
>>>
>>> d.year means the same thing if d is either a date or a datetime, but for 
>>> a duration calling it d.years emphasizes the difference.
>>>
>>> It could perhaps help catch errors as well, both for the human and the 
>>> compiler.
>>> One (arguably contrived) example would be structurally typed code which 
>>> doesn't enforce any type in particular but uses the dot access or partial 
>>> pattern matches like %{year: ..., month: ...} in order to support both 
>>> dates or datetimes. Passing in a duration wouldn't make sense semantically, 
>>> having different names would make it fail properly.
>>>
>>> I also agree with other reasons mentioned, the known standard one 
>>> especially.
>>>
>>> Le jeu. 7 mars 2024 à 16:07, 'Theo Fiedler' via elixir-lang-core <
>>> elixir-l...@googlegroups.com> a écrit :
>>>
>>>> Right, it would make using a Duration in combination with the `add/2-3` 
>>>> functions much harder than it needs to be. So far all time units in Elixir 
>>>> are singular, and I think we do gain something from consistently sticking 
>>>> to that, regardless of the context of durations, calendar types and what 
>>>> not.
>>>>
>>>> I've seen some libraries allowing both, singular and plural, which i 
>>>> dont want to have anything to do with, except for mentioning it though 
>>>> haha.
>>>>
>>>> What i currently see is:
>>>>
>>>> Reasons for plural:
>>>> - Known standard across various libraries and programming languages
>>>> - Sounds natural, to shift a date by "3 months" instead of "3 month".
>>>>
>>>> Reasons for singular:
>>>> - Compatible with time units already defined in Elixir (also relevant 
>>>> for extending the use of Duration later on)
>>>> - Reduced cognitive load as the time units are always spelled the same 
>>>> regardless of the context
>>>>
>>>> The reasons for singular do outweigh the reasons for plural, so unless 
>

Re: [elixir-core:11687] [Proposal] Add `shift/2-3` to calendar types

[Kip Cole]

logical durations to calendar types. e.g. adding a month, a week, or one month and 10 days to a date.Reasons for itWhile similar functionality exists in libraries, such as CLDR, Timex, Tox, adding this functionality to the standard library has already been requested and discussed at multiple occasions over the past years. To list a few examples:- https://github.com/elixir-lang/elixir/pull/10199- https://elixirforum.com/t/get-date-n-months-years-in-the-past/48346/3- https://elixir-lang.slack.com/archives/C0HEX82NR/p1709581478427009?thread_ts=1709368588.334759=C0HEX82NRFurthermore the shift behaviour in the extremely popular library Timex changed in Elixir >= 1.14.3 which may have complicated the mostly lean and non-breaking language upgrade Elixir has to offer.Elixir has a great set of modules and functions that deal with date and time, the APIs are consistent and `shift/2-3` should fit right in, solving many standard needs of various industries, be it for reporting, appointments, events, finance... the list goes on, engineers probably face the need to shift time logically more often than not in their careers.Technical detailsDurationA date or time must be shifted by a duration. There is an ISO8601 for durations, which the initial implementation is loosely following. The structure of a Duration lives in its own module with its own set of functions to create and manipulate durations. One example of where it diverts from the ISO standard, is that it implements microseconds. Microseconds in a duration are stored in the same format as in the time calendar types, meaning they integrate well and provide consistency.ShiftThe shift behaviour is implemented as a callback on Calendar and supported by all calendar types: Date, DateTime, NaiveDateTime and Time. Date, Time and NaiveDateTime each have their own implementation of a "shift", while DateTime gets converted to a NaiveDateTime before applying the shift, and is then rebuilt to a DateTime in its original timezone. `shift/2-3` also has guaranteed output types (which isn't a given in many libraries) and follows the consistent API which is established in the calendar modules.Find the current state of the implementation here: https://github.com/elixir-lang/elixir/pull/13385BenchmarksThere are some benchmarks + StreamData tests in the PR description.OutlookAfter  adding the Duration type and shift behaviour to the standard library, the following things could be explored and derived from the initial work:Implementing a protocol that allows Duration to be applied to any data type, not just dates and times.A range-like data type that allows us to do recurring constructs on any data type. For example, Duration.interval(~D[2000-01-01], month: 1), when iterated, would emit {:ok, date} | {:error, start, duration, reason} entriesA sigil for easy creation of durations: ~P[3 hours and 10 minutes]Making it so add/2-3 reuses the shift_* functionsReasons against itWhile I am convinced that adding `shift/2-3` to the standard library would be very beneficial, nothing really speaks against the points mentioned above to be implemented in a library instead. However, something as crucial and central as date/time manipulation should still be part of the standard library, negating the risk of breaking changes, inconsistent behaviour and outdated or too unique ergonomics which aren't widely applicable, unlike what should be part of the standard library.Many thanks to @jose & @kip for the initial reviews and everyone in advance taking the time to read the proposal!Looking forward to hear other peoples ideas and opinions on the subject!



-- 
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/cb0ed628-3848-4de0-aa13-c0f4761e4d99n%40googlegroups.com.




-- 
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%2BNmFsMhbkRubMjnmM8c_Amq8DgmKCJtzJ1GEuM4-sVgw%40mail.gmail.com.




-- 
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/CAPxxbtjvFwnMXe134RR8wjnYk%2Bm-%2BF%2BO_79dWKk3G-bt99Ln%2Bw%40mail.gmail.com.






-- 
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving em

Re: [elixir-core:11685] [Proposal] Add `shift/2-3` to calendar types

[Kip Cole]

> 
>>>>>>> I would love to hear the community thoughts.
>>>>>>> 
>>> 
>>> 
>>>>>>> On Wed, Mar 6, 2024 at 7:16 PM 'Theo Fiedler' via elixir-lang-core 
>>>>>>> > wrote:
>>> 
>>> 
>>>>>>>> Preface
>>>>>>>> 
>>>>>>>> We currently have `add/2-3` to manipulate calendar types in the 
>>>>>>>> standard library. These functions allow adding a specified amount of 
>>>>>>>> time of given unit to a date/time. The standard library currently 
>>>>>>>> misses means to apply more complex, or logical durations to calendar 
>>>>>>>> types. e.g. adding a month, a week, or one month and 10 days to a date.
>>>>>>>> 
>>>>>>>> Reasons for it
>>>>>>>> 
>>>>>>>> While similar functionality exists in libraries, such as CLDR, Timex, 
>>>>>>>> Tox, adding this functionality to the standard library has already 
>>>>>>>> been requested and discussed at multiple occasions over the past 
>>>>>>>> years. To list a few examples:
>>>>>>>> 
>>>>>>>> - https://github.com/elixir-lang/elixir/pull/10199
>>>>>>>> - https://elixirforum.com/t/get-date-n-months-years-in-the-past/48346/3
>>>>>>>> - 
>>>>>>>> https://elixir-lang.slack.com/archives/C0HEX82NR/p1709581478427009?thread_ts=1709368588.334759=C0HEX82NR
>>>>>>>> 
>>>>>>>> Furthermore the shift behaviour in the extremely popular library Timex 
>>>>>>>> changed <https://github.com/bitwalker/timex/issues/731> in Elixir >= 
>>>>>>>> 1.14.3 which may have complicated the mostly lean and non-breaking 
>>>>>>>> language upgrade Elixir has to offer.
>>>>>>>> 
>>>>>>>> Elixir has a great set of modules and functions that deal with date 
>>>>>>>> and time, the APIs are consistent and `shift/2-3` should fit right in, 
>>>>>>>> solving many standard needs of various industries, be it for 
>>>>>>>> reporting, appointments, events, finance... the list goes on, 
>>>>>>>> engineers probably face the need to shift time logically more often 
>>>>>>>> than not in their careers.
>>>>>>>> 
>>>>>>>> Technical details
>>>>>>>> 
>>>>>>>> Duration
>>>>>>>> A date or time must be shifted by a duration. There is an ISO8601 for 
>>>>>>>> durations <https://en.wikipedia.org/wiki/ISO_8601#Durations>, which 
>>>>>>>> the initial implementation is loosely following. The structure of a 
>>>>>>>> Duration lives in its own module with its own set of functions to 
>>>>>>>> create and manipulate durations. One example of where it diverts from 
>>>>>>>> the ISO standard, is that it implements microseconds. Microseconds in 
>>>>>>>> a duration are stored in the same format as in the time calendar 
>>>>>>>> types, meaning they integrate well and provide consistency.
>>>>>>>> 
>>>>>>>> Shift
>>>>>>>> The shift behaviour is implemented as a callback on Calendar and 
>>>>>>>> supported by all calendar types: Date, DateTime, NaiveDateTime and 
>>>>>>>> Time. Date, Time and NaiveDateTime each have their own implementation 
>>>>>>>> of a "shift", while DateTime gets converted to a NaiveDateTime before 
>>>>>>>> applying the shift, and is then rebuilt to a DateTime in its original 
>>>>>>>> timezone. `shift/2-3` also has guaranteed output types (which isn't a 
>>>>>>>> given in many libraries) and follows the consistent API which is 
>>>>>>>> established in the calendar modules.
>>>>>>>> 
>>>>>>>> Find the current state of the implementation here: 
>>>>>>>> https://github.com/elixir-lang/elixir/pull/13385
>>>>>>>> 
>>>>>>>> Benchmarks
>>>>>>>> 
>>>>>>>> There are some benchmarks + 

Re: [elixir-core:11680] [Proposal] Add `shift/2-3` to calendar types

[Kip Cole]

gt;>> and NaiveDateTime each have their own implementation of a "shift", while 
>>>> DateTime gets converted to a NaiveDateTime before applying the shift, and 
>>>> is then rebuilt to a DateTime in its original timezone. `shift/2-3` also 
>>>> has guaranteed output types (which isn't a given in many libraries) and 
>>>> follows the consistent API which is established in the calendar modules.
>>>> 
>>>> Find the current state of the implementation here: 
>>>> https://github.com/elixir-lang/elixir/pull/13385
>>>> 
>>>> Benchmarks
>>>> 
>>>> There are some benchmarks + StreamData tests in the PR description.
>>>> 
>>>> Outlook
>>>> 
>>>> After  adding the Duration type and shift behaviour to the standard 
>>>> library, the following things could be explored and derived from the 
>>>> initial work:
>>>> 
>>>> Implementing a protocol that allows Duration to be applied to any data 
>>>> type, not just dates and times.
>>>> A range-like data type that allows us to do recurring constructs on any 
>>>> data type. For example, Duration.interval(~D[2000-01-01], month: 1), when 
>>>> iterated, would emit {:ok, date} | {:error, start, duration, reason} 
>>>> entries
>>>> A sigil for easy creation of durations: ~P[3 hours and 10 minutes]
>>>> Making it so add/2-3 reuses the shift_* functions
>>>> Reasons against it
>>>> 
>>>> While I am convinced that adding `shift/2-3` to the standard library would 
>>>> be very beneficial, nothing really speaks against the points mentioned 
>>>> above to be implemented in a library instead. However, something as 
>>>> crucial and central as date/time manipulation should still be part of the 
>>>> standard library, negating the risk of breaking changes, inconsistent 
>>>> behaviour and outdated or too unique ergonomics which aren't widely 
>>>> applicable, unlike what should be part of the standard library.
>>>> 
>>>> Many thanks to @jose & @kip for the initial reviews and everyone in 
>>>> advance taking the time to read the proposal!
>>>> 
>>>> Looking forward to hear other peoples ideas and opinions on the subject!
>>>> 
>>>> -- 
>>>> 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 
>>>> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/elixir-lang-core/cb0ed628-3848-4de0-aa13-c0f4761e4d99n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/elixir-lang-core/cb0ed628-3848-4de0-aa13-c0f4761e4d99n%40googlegroups.com?utm_medium=email_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 
>>> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BNmFsMhbkRubMjnmM8c_Amq8DgmKCJtzJ1GEuM4-sVgw%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BNmFsMhbkRubMjnmM8c_Amq8DgmKCJtzJ1GEuM4-sVgw%40mail.gmail.com?utm_medium=email_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 
>> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/CAPxxbtjvFwnMXe134RR8wjnYk%2Bm-%2BF%2BO_79dWKk3G-bt99Ln%2Bw%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/elixir-lang-core/CAPxxbtjvFwnMXe134RR8wjnYk%2Bm-%2BF%2BO_79dWKk3G-bt99Ln%2Bw%40mail.gmail.com?utm_medium=email_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 
> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BNWO687y8hOWhGFLLAWWF_bwJ8bJ1%3Dd%3DPOWgH9a%3DfdYQ%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BNWO687y8hOWhGFLLAWWF_bwJ8bJ1%3Dd%3DPOWgH9a%3DfdYQ%40mail.gmail.com?utm_medium=email_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/36B8F628-73AB-44FC-A1BD-714ED8008B18%40gmail.com.

[elixir-core:11598] Re: [Proposal] `as: level` for deprecrated attribute

[Kip]

A few thoughts, only to aid the conversation:

1. As a library writer I do feel the need to ensure compiler warnings are 
eradicated during the RC cycle of the next Elixir release.  While this 
definitely puts pressure on me (Im maintaining around 40 libs at the 
moment), it does act as a strong motivator to keep up-to-date and minimise 
DX issues for consumers.  I'm not sure I would trust myself to just lower 
the log level and never come back.

2. We do already have the hard deprecation `@deprecated` and soft 
deprecation `@doc deprecated: "Some deprecation notice"`. Do you not think 
that caters for much of what you propose? 
See 
https://hexdocs.pm/elixir/1.15.4/writing-documentation.html#documentation-metadata
 
Yes, I appreciate they both still emit warning messages, but only one of 
them halts compilation with `--warnings-as-errors`.



On Tuesday, November 21, 2023 at 5:00:42 AM UTC+7 erlef.bry...@gmail.com 
wrote:

>  It's often the case that a project values using `--warnings-as-errors`, 
> yet the `deprecation` attribute conflicts with this option, in that it may 
> be some time before a function gets hard deprecated. What's more, the 
> function might be utilized across many modules such that it's not 
> reasonable nor safe to update all modules all the same time. 
>
> After discussing this issue with Scott Southworth, we ended up with what 
> seemed like a useful addition to `deprecated` attribute, an `:as` option 
> that takes a log level argument.  
>
> This conceivably would ease the adoption process of updated libraries that 
> have soft deprecated functions or modules. This would allow a library 
> author to set the deprecation to log level to `:notice` (as an example). 
> When a "stronger" deprecation is deemed advantageous, library authors can 
> change this to warning, and perhaps lib authors may even opt to switch to 
> the error level before completely removing a function (though, how useful 
> that would be is not clear). 
>
> This has been discussed in the past I do believe, but iirc it was around 
> filtering specific warnings from specific deps vs an extension to the 
> `deprecated` attribute.  
>
> Cheers.
>

-- 
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/0579affe-a9b2-4e50-bd81-b47962b7356dn%40googlegroups.com.

Re: [elixir-core:11552] Re: [Proposal] U+FFFD Substitution of Maximal Subparts

[Kip]

Cameron, I think this would be a useful addition to the Unicode library 
<https://github.com/elixir-unicode/unicode> I maintain. If that works for 
you, please open an issue there and we can collaborate.  I think it being 
part of the Erlang `:unicode` module makes good sense too as José says but 
that's a longer "sales" and implementation cycle.

On Saturday, October 7, 2023 at 7:40:50 PM UTC+11 José Valim wrote:

> Hi Cameron,
>
> If the goal is to include this handling for UTF-16 and UTF-32, I suggest 
> proposing this to Erlang/OTP as new functions in the "unicode" module. 
> Otherwise, Elixir only has facilities to deal with UTF-8. You could propose 
> such a feature in their issues tracker.
>
> Also note that "rolling your own" or "depending on packages" is usually 
> not enough reasons for adding features to Elixir. Otherwise, one could 
> easily argue Decimal and Jason would be more important additions to the 
> language. :) We do describe which features we would consider part of the 
> language here: https://elixir-lang.org/development.html
>
> Other than that, awesome job on the library and benchmarks. :)
>
> On Sat, Oct 7, 2023 at 1:03 AM Kip  wrote:
>
>> Your implementation is definitely fast and memory efficient so I retract 
>> my implementation comments. Now that I've run the benchmarking script and 
>> tested out a few different approaches leveraging the std lib I understand 
>> better why you've taken the approach you have. Nice work.
>>
>> On Saturday, October 7, 2023 at 9:26:37 AM UTC+11 Kip wrote:
>>
>>> Cameron, I think this is a useful proposal.  Elixir has means to check 
>>> validity (String.valid?/1) and a mechanism to split valid and invalid code 
>>> points (String.chunk/2 with the :valid trait). But there isn't, to my 
>>> knowledge, a means to coerce validity.  A couple of thoughts:
>>>
>>> 1. Since Elixir strings are, by definition, UTF8, I don't know that 
>>> special handling of UTF16 and UTF32 code points makes much sense - although 
>>> I accept this may be more Unicode compliant.
>>> 2. What would the function be called? Since we have String.valid?/1 
>>> maybe String.validate/2 with an option `replace_invalid: utf8_string`. The 
>>> default `:replace_invalid` could be U+FFFD or it could be `nil`.   If 
>>> the default is `nil` then there could also be a `String.validate!/2` that 
>>> raises if there is no `:replace_invalid` option.
>>> 3. I think the implementation could leverage the code of 
>>> `String.chunk/2` which uses `String.next_codepoint/1`. That would simplify 
>>> implementation and be more consistent in code style.
>>>
>>> On Friday, October 6, 2023 at 12:24:28 PM UTC+11 cameron...@gmail.com 
>>> wrote:
>>>
>>>> As far as I can tell, neither Elixir nor Erlang have a built in 
>>>> function for replacing invalid sequences in Unicode. There's a suggested 
>>>> method on this page 
>>>> <https://www.unicode.org/versions/Unicode15.0.0/UnicodeStandard-15.0.pdf#page=153>
>>>>  
>>>> of the Unicode standard for handling this. Several other languages (Go 
>>>> <https://pkg.go.dev/bytes#ToValidUTF8>, Python 
>>>> <https://docs.python.org/3/library/stdtypes.html#bytes.decode>, C# 
>>>> <https://github.com/dotnet/docs/issues/13547>, etc) now follow this 
>>>> spec.
>>>>
>>>> Invalid Unicode's encountered frequently enough that I think it's worth 
>>>> incorporating a solution into Elixir itself. 
>>>>
>>>> Present alternatives to handling invalid unicode (and json by extension 
>>>> <https://github.com/michalmuskala/jason/issues/174>) are:
>>>>
>>>>- Crashing (not ideal in many cases) 
>>>>- Roll your own (lot of overhead for accidental complexity)
>>>>- Depend on a package (+1 package towards dependency hell)
>>>>
>>>> This is my college try 
>>>> <https://github.com/Moosieus/UniRecover/tree/main>, but I'm certain 
>>>> there's a performant and far cleaner solution to be had in pure Elixir. If 
>>>> not, perhaps this is a request for OTP.
>>>>
>>> -- 
>> 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/197620a2-6a96-41c6-a6e7-5da03e351080n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/elixir-lang-core/197620a2-6a96-41c6-a6e7-5da03e351080n%40googlegroups.com?utm_medium=email_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/3d19d843-ba6d-4c84-9942-c0ee9129be01n%40googlegroups.com.

[elixir-core:11550] Re: [Proposal] U+FFFD Substitution of Maximal Subparts

[Kip]

Your implementation is definitely fast and memory efficient so I retract my 
implementation comments. Now that I've run the benchmarking script and 
tested out a few different approaches leveraging the std lib I understand 
better why you've taken the approach you have. Nice work.

On Saturday, October 7, 2023 at 9:26:37 AM UTC+11 Kip wrote:

> Cameron, I think this is a useful proposal.  Elixir has means to check 
> validity (String.valid?/1) and a mechanism to split valid and invalid code 
> points (String.chunk/2 with the :valid trait). But there isn't, to my 
> knowledge, a means to coerce validity.  A couple of thoughts:
>
> 1. Since Elixir strings are, by definition, UTF8, I don't know that 
> special handling of UTF16 and UTF32 code points makes much sense - although 
> I accept this may be more Unicode compliant.
> 2. What would the function be called? Since we have String.valid?/1 maybe 
> String.validate/2 with an option `replace_invalid: utf8_string`. The 
> default `:replace_invalid` could be U+FFFD or it could be `nil`.   If the 
> default is `nil` then there could also be a `String.validate!/2` that 
> raises if there is no `:replace_invalid` option.
> 3. I think the implementation could leverage the code of `String.chunk/2` 
> which uses `String.next_codepoint/1`. That would simplify implementation 
> and be more consistent in code style.
>
> On Friday, October 6, 2023 at 12:24:28 PM UTC+11 cameron...@gmail.com 
> wrote:
>
>> As far as I can tell, neither Elixir nor Erlang have a built in function 
>> for replacing invalid sequences in Unicode. There's a suggested method on 
>> this page 
>> <https://www.unicode.org/versions/Unicode15.0.0/UnicodeStandard-15.0.pdf#page=153>
>>  
>> of the Unicode standard for handling this. Several other languages (Go 
>> <https://pkg.go.dev/bytes#ToValidUTF8>, Python 
>> <https://docs.python.org/3/library/stdtypes.html#bytes.decode>, C# 
>> <https://github.com/dotnet/docs/issues/13547>, etc) now follow this spec.
>>
>> Invalid Unicode's encountered frequently enough that I think it's worth 
>> incorporating a solution into Elixir itself. 
>>
>> Present alternatives to handling invalid unicode (and json by extension 
>> <https://github.com/michalmuskala/jason/issues/174>) are:
>>
>>- Crashing (not ideal in many cases) 
>>- Roll your own (lot of overhead for accidental complexity)
>>- Depend on a package (+1 package towards dependency hell)
>>
>> This is my college try <https://github.com/Moosieus/UniRecover/tree/main>, 
>> but I'm certain there's a performant and far cleaner solution to be had in 
>> pure Elixir. If not, perhaps this is a request for OTP.
>>
>

-- 
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/197620a2-6a96-41c6-a6e7-5da03e351080n%40googlegroups.com.

[elixir-core:11549] Re: [Proposal] U+FFFD Substitution of Maximal Subparts

[Kip]

Cameron, I think this is a useful proposal.  Elixir has means to check 
validity (String.valid?/1) and a mechanism to split valid and invalid code 
points (String.chunk/2 with the :valid trait). But there isn't, to my 
knowledge, a means to coerce validity.  A couple of thoughts:

1. Since Elixir strings are, by definition, UTF8, I don't know that special 
handling of UTF16 and UTF32 code points makes much sense - although I 
accept this may be more Unicode compliant.
2. What would the function be called? Since we have String.valid?/1 maybe 
String.validate/2 with an option `replace_invalid: utf8_string`. The 
default `:replace_invalid` could be U+FFFD or it could be `nil`.   If the 
default is `nil` then there could also be a `String.validate!/2` that 
raises if there is no `:replace_invalid` option.
3. I think the implementation could leverage the code of `String.chunk/2` 
which uses `String.next_codepoint/1`. That would simplify implementation 
and be more consistent in code style.

On Friday, October 6, 2023 at 12:24:28 PM UTC+11 cameron...@gmail.com wrote:

> As far as I can tell, neither Elixir nor Erlang have a built in function 
> for replacing invalid sequences in Unicode. There's a suggested method on 
> this page 
> 
>  
> of the Unicode standard for handling this. Several other languages (Go 
> , Python 
> , C# 
> , etc) now follow this spec.
>
> Invalid Unicode's encountered frequently enough that I think it's worth 
> incorporating a solution into Elixir itself. 
>
> Present alternatives to handling invalid unicode (and json by extension 
> ) are:
>
>- Crashing (not ideal in many cases) 
>- Roll your own (lot of overhead for accidental complexity)
>- Depend on a package (+1 package towards dependency hell)
>
> This is my college try , 
> but I'm certain there's a performant and far cleaner solution to be had in 
> pure Elixir. If not, perhaps this is a request for OTP.
>

-- 
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/6ee07b4d-f0fc-44fe-8644-75db20f42397n%40googlegroups.com.

Re: [elixir-core:11410] [Proposal] Add function average or avg to Enum module.

[Kip]

I would not be in favour of adding average to Enum for the simple reason 
that there is no guarantee that average has meaning for a given enumerable. 
Its Erlang's term ordering rules than mean max and min have meaning for all 
terms. That is not true for averages. 

On Monday, May 22, 2023 at 10:25:36 AM UTC-10 Andrey Yugai wrote:

> Whether any function is worth of stdlib is a really subtle topic, but I 
> think it'd be helpful to try to consider why average function hasn't been 
> added yet. 
>
> From my experience, the order on any kind of elements comes up pretty 
> often, thus min/max values are widely used. In the same vein sum also tends 
> to pop up whenever some sort of data processing happens. 
>
> Now, there are domains that involve number crunching, and within them it's 
> imperative to have average, mode, median and whatnot to achieve any result. 
> But it's important to have in mind these are more specialized applications 
> of a language. They're far better served in external libraries, allowing 
> users to make a choice of not including this functionality in app, and also 
> enabling the most efficient implementation possible, like Nx having its own 
> compilation pipeline to bypass limitations of BEAM. 
>
>
>
>
>
>  Original Message 
> On 23 May 2023, 03:05, Julian Somoza < julian...@gmail.com> wrote:
>
>
> Just as is there a function to get the *min,* *max, sum, *etc values from 
> an Enum, would be useful to have also an average function.
>
> Enum.avg/1 or Enum.average/1
>
> If it's ok for the community, I will be happy to implement it.
>
> Example:
>
> iex> Enum.avg(0..10)
> 5
>
> -- 
> 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/CACFi_YPY5QURbQ8G%3DqA%3Dt6iQLWUToQygU-jo1%2BzdmW%3DFE3EmKw%40mail.gmail.com
>  
> 
> .
>
>

-- 
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/fc56f73c-9839-476a-8c6c-65a809a122a1n%40googlegroups.com.

Re: [elixir-core:11393] Proposal: Add ~URI sigil

[Kip Cole]

I think this is a good proposal, as is the ~UTC one.  Both make the intent much 
clearer.

> On 16 May 2023, at 6:45 pm, Wojtek Mach  wrote:
> 
> I just realised another small benefit of showing the full URL in the sigil. 
> Here’s a snippet from the proposal as rendered by my e-mail client:
> 
> 
> 
> The URL was automatically made clickable. Tools like Livebook could 
> potentially do the same.
> 
>> On 16 May 2023, at 10:38, Wojtek Mach > > wrote:
>> 
>> Hi, I'd like to propose adding ~URI for constructing URI structs. Here's an 
>> example:
>> 
>> iex> ~URI"https://elixir-lang.org "
>> %URI{
>>   scheme: "https",
>>   authority: "elixir-lang.org ",
>>   userinfo: nil,
>>   host: "elixir-lang.org ",
>>   port: 443,
>>   path: nil,
>>   query: nil,
>>   fragment: nil
>> }
>> 
>> I believe the advantage is we can make this a macro and thus parse the URI 
>> string at compile-time
>> so catch bugs because of incorrect format early (though these are pretty 
>> uncommon) and also be a
>> little bit more efficient at runtime.
>> 
>> If added, I'm not sure whether ~URI should use URI.parse or URI.new! under 
>> the hood so an advice
>> on that would be appreciated.
>> 
>> This is a separate but related discussion so while at it, I'd like to 
>> propose adding Inspect
>> implementation for URI that would return the sigil:
>> 
>> iex> ~URI"https://elixir-lang.org "
>> ~URI"https://elixir-lang.org "
>> 
>> I think more compact representation helps e.g. here. Before:
>> 
>> iex> Req.new(url: "https://elixir-lang.org ")
>> %Req.Request{
>>   method: :get,
>>   url: %URI{
>> scheme: "https",
>> authority: "elixir-lang.org ",
>> userinfo: nil,
>> host: "elixir-lang.org ",
>> port: 443,
>> path: nil,
>> query: nil,
>> fragment: nil
>>   },
>>   headers: [],
>>   body: nil,
>>   options: %{},
>>   ...
>> }
>> 
>> After:
>> 
>> iex> Req.new(url: "https://elixir-lang.org ")
>> %Req.Request{
>>   method: :get,
>>   url: ~URI"https://elixir-lang.org ",
>>   headers: [],
>>   body: nil,
>>   options: %{},
>>   ...
>> }
>> 
>> On the other hand, seeing the internal representation right away is 
>> sometimes useful given the URI
>> format is somewhat subtle.
>> 
>> Before:
>> 
>> iex> URI.parse("/foo")
>> %URI{
>>   scheme: nil,
>>   userinfo: nil,
>>   host: nil,
>>   port: nil,
>>   path: "/foo",
>>   query: nil,
>>   fragment: nil
>> }
>> iex> URI.parse("//foo")
>> %URI{
>>   scheme: nil,
>>   authority: "foo",
>>   userinfo: nil,
>>   host: "foo",
>>   port: nil,
>>   path: nil,
>>   query: nil,
>>   fragment: nil
>> }
>> 
>> After:
>> 
>> iex> URI.parse("/foo")
>> ~URI"/foo"
>> iex> URI.parse("//foo")
>> ~URI"//foo"
>> 
>> I think this downside can be alleviated by adding `IEx.Info` implementation 
>> along these lines:
>> 
>> iex> i URI.parse("/foo")
>> Term
>>   ~URI"/foo"
>> Data type
>>   URI
>> Raw representation
>>   %URI{
>> scheme: nil,
>> userinfo: nil,
>> host: nil,
>> port: nil,
>> path: "/foo",
>> query: nil,
>> fragment: nil
>>   }
>> 
>> -- 
>> 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/9cc29c5e-ca64-42b3-83f8-84c60985efedn%40googlegroups.com
>>  
>> .
> 
> 
> -- 
> 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/5D183EE3-56B8-41BB-8D23-5014C72EA0BE%40wojtekmach.pl
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from 

Re: [elixir-core:11343] [Proposal] Add Duration Module

[Kip Cole]

I do think there is room in Elixir core for something that simplifies 
interval/duration handling - primarily because time is hard.   I continue to 
work on Tempo[1] and because its ISO8601 (Parts 1 and 2) compliant perhaps 
there are some things than it might demonstrate as opportunities for Elixir. 
I’ve got some major milestones this week on other libs but I will be back hard 
onto Tempo after that.  José always reminds me that eventually I need to deal 
with timezones. I think I have a reasonable model in mind for that now, based 
upon PEP 495 [2]  and I think I’ve got a good model for interval shifts and 
interval algebra. But its going to take a couple of months before I have 
another major update ready for public review.  (It is the lib I’m most 
motivated to get to completed and polished).

I’m always happy to collaborate time and calendar proposals specific for Elixir 
core if some else can take the lead.

[1] https://github <https://github/>.com/kipcole9/tempo
[2] https://peps.python.org/pep-0495/ <https://peps.python.org/pep-0495/>





> On 10 Apr 2023, at 3:20 pm, José Valim  wrote:
> 
> Hi Yordis, thank you for the proposal.
> 
> I would like to see it expanded to say how such module you would look like 
> and how it would interact with all the other Calendar modules.
> 
> Kip also had a library where the dates and datetimes themselves could be 
> duration and I would want to see them explored too.
> 
> Thanks.
> 
> On Mon, Apr 10, 2023 at 00:29 Yordis Prieto  <mailto:yordis.pri...@gmail.com>> wrote:
> Add Duration module to enhance its time-handling capabilities. Several modern 
> programming ecosystems, such as Rust, .NET, Go, and Java, already have 
> similar modules that prove invaluable to their communities.
> 
> - https://hexdocs.pm/timex/Timex.Duration.html 
> <https://hexdocs.pm/timex/Timex.Duration.html>
> - https://doc.rust-lang.org/stable/std/time/struct.Duration.html 
> <https://doc.rust-lang.org/stable/std/time/struct.Duration.html>- 
> https://learn.microsoft.com/en-us/dotnet/api/system.timespan?view=net-6.0 
> <https://learn.microsoft.com/en-us/dotnet/api/system.timespan?view=net-6.0>
> - https://pkg.go.dev/time#Duration <https://pkg.go.dev/time#Duration>
> - https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html 
> <https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html>
> 
> Key reasons to add a Duration module to Elixir:
> 
> - Enhanced Time Handling: Complements Elixir's existing time modules for a 
> more comprehensive solution.
> - Improved Compatibility: Promotes better interoperability and smoother 
> transitions for developers migrating to Elixir.
> - Alignment with Modern Ecosystems: Ensures Elixir remains up-to-date with 
> the features expected from a modern programming language.
> - Enhanced Readability and Maintainability: Simplifies working with time 
> intervals, resulting in more readable and maintainable code.
> 
> I would appreciate your consideration and feedback on this proposal. Adding a 
> Duration module would significantly improve Elixir's time-handling 
> capabilities, making it an even more attractive choice for developers.
> 
> Thank you so much for your consideration.
> 
> 
> -- 
> 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 
> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/elixir-lang-core/9450ba64-2f80-4ce4-84c4-cfb60d1c952en%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/elixir-lang-core/9450ba64-2f80-4ce4-84c4-cfb60d1c952en%40googlegroups.com?utm_medium=email_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 
> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BYUULr8ahwXeK149fGO%3D-ZSGaOqA_iHJacYroj7QmNMw%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BYUULr8ahwXeK149fGO%3D-ZSGaOqA_iHJacYroj7QmNMw%40mail.gmail.com?utm_medium=email_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/9D81F44B-C1FB-4F97-A4C0-02066CFAA223%40gmail.com.

Re: [elixir-core:11192] Re: Proposal: Introduce string limit function.

[Kip]

> for rendering strings in UIs

This is the bit that concerns me about user expectations. Rendering to a 
specific length can really only be done by the render engine since 
characters, kerning and spacing are variable width.  The widest I know of 
is the single grapheme "﷽". And that also doesn't account for the unicode 
characters that do not take up space. 

A minor nit is that I think the truncation is expected to be the total 
length of the string including the padding. So `leading <> padding ` would 
need to be trim the padding length from leading first.

On Sunday, November 20, 2022 at 5:43:24 AM UTC+1 zachary@gmail.com 
wrote:

> It would be great to come up with some kind of heuristic and/or consistent 
> philosophy on what belongs in the standard library, to guide these 
> discussions. Some kind of rubric could make these kinds of conversations 
> easier or even prevent them entirely. For me, the main guiding principles 
> are whether or not there is exactly one right way to do the thing in 
> question, how ubiquitous the need for it is, and how obvious the 
> implementation is (on the flipside, how much we can prevent people from 
> hidden gotchas they wouldn't even think to reach for a library for). 
>
> For example, the implementation actually requires only adding padding if 
> the string has been trimmed at all, and I'd bet there are lots of 
> suboptimal implementations out there. Ben's above isn't quite right, since 
> the idea is to only add the ellipses if it truncated the string, and then 
> it should only add exactly the string provided (not pad it out to the full 
> length of the string).  Since a performant implementation probably might 
> not be quite as obvious to the less experienced (with elixir or in 
> general), and this seems like a relatively common operation (for rendering 
> strings in UIs or emails or w/e), I feel like a std library implementation 
> could be warranted.
>
> Something like this would probably be better since it avoids checking the 
> string length (a linear time operation) and also avoids things like 
> multiple slice operations in favor of a single traversal up to "length".
>
> ```
> def truncate("", 0, _), do: ""
> def truncate(_, 0, padding), do: padding
>
> def truncate(string, length, padding) when length > 0 do
>   case String.split_at(string, length) do
> {leading, ""} -> leading
> {leading, _} -> leading <> padding
>   end
> end
> ```
>
>
>
> On Sat, Nov 19 2022 at 9:45 PM, Ben Wilson  wrote: 
>
>> This seems reasonably straight forward to implement in your own code base:
>>
>> ```
>> def truncate(string, length, padding \\ ".") do
>>   string
>>   |> String.slice(0, length)
>>   |> String.pad_trailing(String.length(string), padding)
>> end
>> ```
>>
>> Not seeing a strong need to include it in the standard library. Just my 
>> $0.02
>> On Saturday, November 19, 2022 at 2:12:19 PM UTC-5 Kip wrote:
>>
>>> That is comes from Laravel, not PHP core may be an indication it is 
>>> better implemented in a library?  If there is momentum towards adding it to 
>>> the String module I think `String.truncate` would feel more natural to me 
>>> (its also what Ruby uses).  
>>>
>>> Its difficult to make guarantees about the printable width though since 
>>> characters like ZWJ and Bidi text would mean that to do this properly is 
>>> not a simple or straight forward situation.  For that reason I don't 
>>> personally think it belongs in Elixir itself.
>>>
>>> On Saturday, November 19, 2022 at 5:20:21 PM UTC+1 hassanr...@gmail.com 
>>> wrote:
>>>
>>>> Hi all,
>>>> I came across from laravel <https://laravel.com> framework, where 
>>>> there are a lot of useful functions, I miss those functions in Elixir, One 
>>>> of the functions is called limit 
>>>> <https://laravel.com/docs/9.x/helpers#method-str-limit> function, I 
>>>> would like to have that in elixir.
>>>> ```
>>>> iex> String.limit("elixir", 3)
>>>> "eli..."
>>>>
>>>> iex> String.limit("elixir", 7)
>>>> "elixir"
>>>>
>>>> iex> String.limit("elixir", 3, "***")
>>>> "eli***"
>>>> ```
>>>> This function would be really helpful with longer string, we can limit 
>>>> long string with some trailing string like (...).
>>>>
>>>> What do you think? If yes wha

[elixir-core:11189] Re: Proposal: Introduce string limit function.

[Kip]

That is comes from Laravel, not PHP core may be an indication it is better 
implemented in a library?  If there is momentum towards adding it to the 
String module I think `String.truncate` would feel more natural to me (its 
also what Ruby uses).  

Its difficult to make guarantees about the printable width though since 
characters like ZWJ and Bidi text would mean that to do this properly is 
not a simple or straight forward situation.  For that reason I don't 
personally think it belongs in Elixir itself.

On Saturday, November 19, 2022 at 5:20:21 PM UTC+1 hassanr...@gmail.com 
wrote:

> Hi all,
> I came across from laravel  framework, where there 
> are a lot of useful functions, I miss those functions in Elixir, One of the 
> functions is called limit 
>  function, I would 
> like to have that in elixir.
> ```
> iex> String.limit("elixir", 3)
> "eli..."
>
> iex> String.limit("elixir", 7)
> "elixir"
>
> iex> String.limit("elixir", 3, "***")
> "eli***"
> ```
> This function would be really helpful with longer string, we can limit 
> long string with some trailing string like (...).
>
> What do you think? If yes what should be the name you suggest?
>
> Thanks,
> Hassan
>
>
>
>

-- 
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/11ad4ce2-27ec-4689-b839-3fcaed21974bn%40googlegroups.com.

[elixir-core:11071] [Proposal] Support Unicode Mathematical Symbols Block as user-defined operators

[Kip]

Today Elixir allows a very flexible set of Unicode characters to form part 
of an identifier (there is a Unicode standard for this).  There is a 
limited set of reserved operators permitted as well.

This proposal seeks to assess if there is any support to some or all of the 
Unicode Mathematical Symbols block to the list of allowed user defined 
operators.

* The increased focus on numerical computation in Elixir could benefit from 
an expressive set of operators

* Certain operators like the "set" (element, union, intersection, ) 
operators reflect the list/set operations in common use in Elixir across 
enumerables, lists, map sets and maps.

* Certain mathematical expressions are more readily expressed with infix 
notation (especially when the implementation represents a formula from 
published works). I am finding this to be true in my own work in Image 
(image processing) and Tempo (time expressions).  I suspect this would be 
true for numerical computations in Nx but have not validated this.

* These operators do no clash with any existing operators so would not 
introduce backward compatibility issues and would require minimal changes 
to the Elixir lexer (an assumption by me)

   1. Mathematical Symbols 
   

   

-- 
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/2d5e34dd-314b-4a5e-b490-f1b8d2c4f096n%40googlegroups.com.

[elixir-core:10720] Re: Can I add the Dekatrian Calendar?

[Kip]

That's quite a simple calendar (other than Acrônian and Synchronion) so I 
suggest look at the Calendar behaviour 
 and then the very simple 
holocene 
calendar 

 that 
is used in Elixir tests.  I've built quite a few Elixir calendars to happy 
to help.

On Monday, January 10, 2022 at 10:40:17 AM UTC+8 phellp...@gmail.com wrote:

> I want to add implements the Dekatrian calendar 
>  for 
> elixir, I want to know if I can do it and how is the steps to do this.
>
>

-- 
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/97d54152-375a-483e-9ef2-210d152d5eeen%40googlegroups.com.

Re: [elixir-core:10073] ISO 8601 ordinal dates

[Kip Cole]

 the basic format does not support extra digits 
> nor negative years. If they do, then there may be ambiguity.
> 
> On Fri, Feb 5, 2021 at 00:22 Christopher Keele > wrote:
> > Here is another question: if we are going to parse ordinals by default, how 
> > am I going to format to the ordinal format? Use strftime exclusively?
> 
> I'm fine with that, to me this is a case of following the parsing spec and 
> being liberal in what we accept, conservative in what we emit (by default).
> 
> On Thursday, February 4, 2021 at 3:20:21 PM UTC-8 Christopher Keele wrote:
> > Ordinal also has both extended and basic forms too.
> 
> Yup, basic/extended can apply to the entire date/time/datetime string (but 
> must be universally applied to it, saving at least some headache).
> 
> > The distinction between basic ordinal and basic DateTime is a single 
> > character
> 
> I agree that basic ordinals is possibly the worst way to format a date, for 
> the reasons you describe. But it is technically unambiguous, and
> 
> > There will also be ambiguity if we ever decide to support more than four 
> > digits on the year.
> 
> This is technically not true for 5-digit years, so long as we choose to use 
> ISO-8601: it has a provision for this by prefixing the year with a plus or 
> minus. This is described as being 'by agreement only' though so omitted from 
> my envisioned scope.
> 
> In fact now that I think about it we are probably violating the spec today: 
> we support negative signs to indicate BC for 4-digit years. By my reading of 
> the spec we should be requiring that negative years supply 5 digits.
> 
> > At this point I wonder why add [ordinal dates] to the stdlib.
> 
> My motive here really is just to be spec-compliant. There may be a point 
> where we decide we are going off-spec to avoid many of the complexities 
> raised in this discussion, happy to have that conversation too (though 
> probably should be its own thread?)
> On Thursday, February 4, 2021 at 3:08:00 PM UTC-8 José Valim wrote:
> Ah, thanks Kip. Ordinal also has both extended and basic forms too.
> 
> Here is another question: if we are going to parse ordinals by default, how 
> am I going to format to the ordinal format? Use strftime exclusively?
> 
> The other annoyance is while an extended ordinal is distinct enough from a 
> regular extended DateTime, the distinction between basic ordinal and basic 
> DateTime is a single character: “2020012134523”. There will also be ambiguity 
> if we ever decide to support more than four digits on the year. This is 
> enough to say that:
> 
> * it is not possible to parse all formats within a single function without 
> additional user instructions 
> 
> * if the basic format supports both regular and ordinal, there can be 
> ambiguity if 5 year digits are ever supported in the future
> 
> This is enough information to me that ordinal should be its own thing, with 
> possibly basic_ordinal and extended_ordinal, but at this point I wonder why 
> add it to the stdlib.
> 
> On Thu, Feb 4, 2021 at 23:50 Kip Cole > wrote:
> From ISO 8601-1:2019(E):
> 
> 5.2.3 Ordinal date
> 
> 
> 5.2.3.1 Complete representations
> 
> A complete representation of an ordinal date shall be as follows.
> 
> a) Basic format: [year][dayo] EXAMPLE 1 1985102
> 
> b) Extended format: [year][“-”][dayo] EXAMPLE 2 1985-102
> 
> If by agreement, expanded representations are used, the formats shall be as 
> specified below. The interchange parties shall agree on the additional number 
> of digits in the time scale component year.
> 
> 5.2.3.2 Expanded representations
> 
> In the examples below it has been agreed to expand the time scale component 
> year with two digits.
> 
> a) Basic format: [±][year(6)][dayo] EXAMPLE 1 +001985102
> 
> b) Extended format: [±][year(6)][“-”][dayo] EXAMPLE 2 +001985-102 
> 
> 
>> On 5 Feb 2021, at 6:45 am, José Valim > wrote:
>> 
>>  
>> I like José's suggesting of supporting a flag, but it gets kind of 
>> complicated as there are several dimensions here even in our reduced case. 
>> Dates, times, and datetimes support either basic or extended notations; 
>> dates and datetimes support calendar dates or ordinal dates; both are 
>> applicable to any parsing.
>> 
>> Are we 100% sure that ordinal datetimes are part of ISO8601? Kip, can you 
>> please confirm?
>>  
>> If we went with this approach I'd lean towards always accepting either form 
>> for one of the dimensions, and using flags to the sigil and parsing 
>> functions to indicate intent for the other.
>> 
>> I am not necessarily worried about sigils because sigils a

Re: [elixir-core:10070] ISO 8601 ordinal dates

[Kip Cole]

sic ordinals is possibly the worst way to format a date, for 
> the reasons you describe. But it is technically unambiguous, and
> 
> > There will also be ambiguity if we ever decide to support more than four 
> > digits on the year.
> 
> This is technically not true for 5-digit years, so long as we choose to use 
> ISO-8601: it has a provision for this by prefixing the year with a plus or 
> minus. This is described as being 'by agreement only' though so omitted from 
> my envisioned scope.
> 
> In fact now that I think about it we are probably violating the spec today: 
> we support negative signs to indicate BC for 4-digit years. By my reading of 
> the spec we should be requiring that negative years supply 5 digits.
> 
> > At this point I wonder why add [ordinal dates] to the stdlib.
> 
> My motive here really is just to be spec-compliant. There may be a point 
> where we decide we are going off-spec to avoid many of the complexities 
> raised in this discussion, happy to have that conversation too (though 
> probably should be its own thread?)
> On Thursday, February 4, 2021 at 3:08:00 PM UTC-8 José Valim wrote:
> Ah, thanks Kip. Ordinal also has both extended and basic forms too.
> 
> Here is another question: if we are going to parse ordinals by default, how 
> am I going to format to the ordinal format? Use strftime exclusively?
> 
> The other annoyance is while an extended ordinal is distinct enough from a 
> regular extended DateTime, the distinction between basic ordinal and basic 
> DateTime is a single character: “2020012134523”. There will also be ambiguity 
> if we ever decide to support more than four digits on the year. This is 
> enough to say that:
> 
> * it is not possible to parse all formats within a single function without 
> additional user instructions 
> 
> * if the basic format supports both regular and ordinal, there can be 
> ambiguity if 5 year digits are ever supported in the future
> 
> This is enough information to me that ordinal should be its own thing, with 
> possibly basic_ordinal and extended_ordinal, but at this point I wonder why 
> add it to the stdlib.
> 
> On Thu, Feb 4, 2021 at 23:50 Kip Cole > wrote:
> From ISO 8601-1:2019(E):
> 
> 5.2.3 Ordinal date
> 
> 
> 5.2.3.1 Complete representations
> 
> A complete representation of an ordinal date shall be as follows.
> 
> a) Basic format: [year][dayo] EXAMPLE 1 1985102
> 
> b) Extended format: [year][“-”][dayo] EXAMPLE 2 1985-102
> 
> If by agreement, expanded representations are used, the formats shall be as 
> specified below. The interchange parties shall agree on the additional number 
> of digits in the time scale component year.
> 
> 5.2.3.2 Expanded representations
> 
> In the examples below it has been agreed to expand the time scale component 
> year with two digits.
> 
> a) Basic format: [±][year(6)][dayo] EXAMPLE 1 +001985102
> 
> b) Extended format: [±][year(6)][“-”][dayo] EXAMPLE 2 +001985-102 
> 
> 
>> On 5 Feb 2021, at 6:45 am, José Valim > wrote:
>> 
>>  
>> I like José's suggesting of supporting a flag, but it gets kind of 
>> complicated as there are several dimensions here even in our reduced case. 
>> Dates, times, and datetimes support either basic or extended notations; 
>> dates and datetimes support calendar dates or ordinal dates; both are 
>> applicable to any parsing.
>> 
>> Are we 100% sure that ordinal datetimes are part of ISO8601? Kip, can you 
>> please confirm?
>>  
>> If we went with this approach I'd lean towards always accepting either form 
>> for one of the dimensions, and using flags to the sigil and parsing 
>> functions to indicate intent for the other.
>> 
>> I am not necessarily worried about sigils because sigils are always 
>> compile-time literals. It is probably fine to enforce a given format there 
>> rather than multiple ones.
>> 
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "elixir-lang-core" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/elixir-lang-core/CcXpeMQhsmU/unsubscribe 
>> <https://groups.google.com/d/topic/elixir-lang-core/CcXpeMQhsmU/unsubscribe>.
>> To unsubscribe from this group and all its topics, 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/CAGnRm4JNeGkCNW_6ic2XkxTkFV3uyMT%2B3EZYJuguhzzZfpOnpQ%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JNeGkCNW_6ic2XkxTkFV3uyMT%2B3EZYJuguhzz

Re: [elixir-core:10064] ISO 8601 ordinal dates

[Kip Cole]

Per the standard:

The Gregorian calendar defines a calendar year to be either 365 or 366 days, 
which begins on January 1 and ends on December 31. Each Gregorian calendar year 
can be identified by a 4-digit ordinal number beginning with ‘’ for year 
zero, through ‘’.

4.3.2 Calendar year and years duration

The calendar year and years duration are represented as follows:

a) Implied: []
EXAMPLE 1 ‘1985’ (calendar year 1985)

b) Explicit: [i][“Y”]
EXAMPLE 2 ‘12Y’ (twelve years)

The number of digits may exceed 4 in the case of expanded representation, in 
which case the year number may be preceded by a minus sign to indicate a year 
preceding year zero.

 

Only the Expanded (by agreement) year allows more than 4 digits and allows a 
sign (+ or -)



> On 5 Feb 2021, at 7:45 am, José Valim  wrote:
> 
> > In fact now that I think about it we are probably violating the spec today: 
> > we support negative signs to indicate BC for 4-digit years. By my reading 
> > of the spec we should be requiring that negative years supply 5 digits.
> 
> My understanding is that the number of extra digit years is adjustable. So it 
> could be  0 extra digits or even 2. To quote Wikipedia:
> 
> > The "basic" format for year 0 is the four-digit form , which equals the 
> > historical year 1 BC. Several "expanded" formats are possible: − and 
> > +, as well as five- and six-digit versions.
> 
> Source: https://en.m.wikipedia.org/wiki/Year_zero 
> <https://en.m.wikipedia.org/wiki/Year_zero>
> 
> I am not sure if this means the basic format does not support extra digits 
> nor negative years. If they do, then there may be ambiguity.
> 
> On Fri, Feb 5, 2021 at 00:22 Christopher Keele  <mailto:christheke...@gmail.com>> wrote:
> > Here is another question: if we are going to parse ordinals by default, how 
> > am I going to format to the ordinal format? Use strftime exclusively?
> 
> I'm fine with that, to me this is a case of following the parsing spec and 
> being liberal in what we accept, conservative in what we emit (by default).
> 
> On Thursday, February 4, 2021 at 3:20:21 PM UTC-8 Christopher Keele wrote:
> > Ordinal also has both extended and basic forms too.
> 
> Yup, basic/extended can apply to the entire date/time/datetime string (but 
> must be universally applied to it, saving at least some headache).
> 
> > The distinction between basic ordinal and basic DateTime is a single 
> > character
> 
> I agree that basic ordinals is possibly the worst way to format a date, for 
> the reasons you describe. But it is technically unambiguous, and
> 
> > There will also be ambiguity if we ever decide to support more than four 
> > digits on the year.
> 
> This is technically not true for 5-digit years, so long as we choose to use 
> ISO-8601: it has a provision for this by prefixing the year with a plus or 
> minus. This is described as being 'by agreement only' though so omitted from 
> my envisioned scope.
> 
> In fact now that I think about it we are probably violating the spec today: 
> we support negative signs to indicate BC for 4-digit years. By my reading of 
> the spec we should be requiring that negative years supply 5 digits.
> 
> > At this point I wonder why add [ordinal dates] to the stdlib.
> 
> My motive here really is just to be spec-compliant. There may be a point 
> where we decide we are going off-spec to avoid many of the complexities 
> raised in this discussion, happy to have that conversation too (though 
> probably should be its own thread?)
> On Thursday, February 4, 2021 at 3:08:00 PM UTC-8 José Valim wrote:
> Ah, thanks Kip. Ordinal also has both extended and basic forms too.
> 
> Here is another question: if we are going to parse ordinals by default, how 
> am I going to format to the ordinal format? Use strftime exclusively?
> 
> The other annoyance is while an extended ordinal is distinct enough from a 
> regular extended DateTime, the distinction between basic ordinal and basic 
> DateTime is a single character: “2020012134523”. There will also be ambiguity 
> if we ever decide to support more than four digits on the year. This is 
> enough to say that:
> 
> * it is not possible to parse all formats within a single function without 
> additional user instructions 
> 
> * if the basic format supports both regular and ordinal, there can be 
> ambiguity if 5 year digits are ever supported in the future
> 
> This is enough information to me that ordinal should be its own thing, with 
> possibly basic_ordinal and extended_ordinal, but at this point I wonder why 
> add it to the stdlib.
> 
> On Thu, Feb 4, 2021 at 23:50 Kip Cole > wrote:
> From ISO 8601-1:2019(E):

Re: [elixir-core:10058] ISO 8601 ordinal dates

[Kip Cole]

>From ISO 8601-1:2019(E):

5.2.3 Ordinal date


5.2.3.1 Complete representations

A complete representation of an ordinal date shall be as follows.

a) Basic format: [year][dayo] EXAMPLE 1 1985102

b) Extended format: [year][“-”][dayo] EXAMPLE 2 1985-102

If by agreement, expanded representations are used, the formats shall be as 
specified below. The interchange parties shall agree on the additional number 
of digits in the time scale component year.

5.2.3.2 Expanded representations

In the examples below it has been agreed to expand the time scale component 
year with two digits.

a) Basic format: [±][year(6)][dayo] EXAMPLE 1 +001985102

b) Extended format: [±][year(6)][“-”][dayo] EXAMPLE 2 +001985-102 


> On 5 Feb 2021, at 6:45 am, José Valim  wrote:
> 
>  
> I like José's suggesting of supporting a flag, but it gets kind of 
> complicated as there are several dimensions here even in our reduced case. 
> Dates, times, and datetimes support either basic or extended notations; dates 
> and datetimes support calendar dates or ordinal dates; both are applicable to 
> any parsing.
> 
> Are we 100% sure that ordinal datetimes are part of ISO8601? Kip, can you 
> please confirm?
>  
> If we went with this approach I'd lean towards always accepting either form 
> for one of the dimensions, and using flags to the sigil and parsing functions 
> to indicate intent for the other.
> 
> I am not necessarily worried about sigils because sigils are always 
> compile-time literals. It is probably fine to enforce a given format there 
> rather than multiple ones.
> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "elixir-lang-core" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/elixir-lang-core/CcXpeMQhsmU/unsubscribe 
> <https://groups.google.com/d/topic/elixir-lang-core/CcXpeMQhsmU/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> elixir-lang-core+unsubscr...@googlegroups.com 
> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JNeGkCNW_6ic2XkxTkFV3uyMT%2B3EZYJuguhzzZfpOnpQ%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JNeGkCNW_6ic2XkxTkFV3uyMT%2B3EZYJuguhzzZfpOnpQ%40mail.gmail.com?utm_medium=email_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/15198E56-9D02-4A0E-8E6D-AB905531112A%40gmail.com.

Re: [elixir-core:10051] ISO 8601 ordinal dates

[Kip Cole]

> Ordinal dates are interesting because while they are not calendar dates, they 
> are trivially convertible into them.

True for the proleptic Gregorian calendar, not necessarily so for other 
calendars. Since ISO8601 is explicitly only concerned with that calendar I 
expect this isn’t an issue.

However given ordinal days of the year do exist for all calendars (that I’m 
aware of since they all have the concept of a day) perhaps adding a callback to 
`Calendar` of something like `month_and_day_from_ordinal(year, ordinal)` would 
be something to consider? Then of course implement that for `Calendar.ISO`.



> On 5 Feb 2021, at 6:16 am, Christopher Keele  wrote:
> 
> Ordinal dates are interesting because while they are not calendar dates, they 
> are trivially convertible into them.

-- 
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/BA38F710-E87F-436D-BDDA-CE76EB10447F%40gmail.com.

Re: [elixir-core:10046] ISO 8601 ordinal dates

[Kip]

I think its important to be careful on the scope.  The ISO8601 spec is vast 
(I am implementing a new lib that implements the whole thing and its a huge 
task) .

> "I think we should probably consider this a bug, and fix functions which 
parse ISO-8601 dates so that they support what's allowed in the ISO-8601 
spec". This is not a realistic goal for Elixir core I think.

Ordinal dates, explicit and implicit forms of dates, century dates, decade 
dates, . thats a lot of surface area for maintenance that in the spirit 
of Elixir probably lies better in an external library if required.


On Thursday, February 4, 2021 at 9:30:32 AM UTC+8 christ...@gmail.com wrote:

> WIP PR available here: https://github.com/elixir-lang/elixir/pull/10687
>
> I've proved the concept, but want to step back and solicit feedback, get 
> some discussion going on explicit points I call out in the PR, and think of 
> ways to clean the implementation up a little.
>
> On Wednesday, February 3, 2021 at 2:53:23 PM UTC-8 br...@grox.io wrote:
>
>> +1
>>
>> On Wed, Feb 3, 2021 at 2:54 PM Christopher Keele  
>> wrote:
>>
>>> As observed by @ryanbigg  on Twitter 
>>> , *"2021-034"* 
>>> is a valid ISO 8601 date.
>>>
>>> Specifically, it is an ordinal date 
>>>  descriptor of the format 
>>> -DDD. Unlike some of the more exotic ISO 8601 formats, like naming a 
>>> week of the year or a day+month without a year; it does fully describe a 
>>> single date in time.
>>>
>>> As Ryan observes, Ruby supports parsing ordinal date strings but Elixir 
>>> does not. Is this something we'd want to add? Honestly the correct 
>>> behaviour here is almost more surprising to me than our lack of support for 
>>> it, but I wanted to field a discussion about it.
>>>
>>> -- 
>>>
>> 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/51e44339-31aa-4ec6-93c8-3ca0f7901926n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>>
>> Regards,
>> Bruce Tate
>> CEO
>>
>>
>> 
>>
>> Groxio, LLC.
>> 512.799.9366 <(512)%20799-9366>
>> br...@grox.io
>> grox.io
>>
>

-- 
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/feb8152e-874c-49e1-a858-7d979d5cdfd4n%40googlegroups.com.

Re: [elixir-core:9516] [Proposal] Support transforming lists to type specs

[Kip]

If its a construct and not a function does that imply changes to the lexer 
and parser? If so, then perhaps $one_of or something else that is not a 
valid identifier in Elixir.

On Saturday, May 16, 2020 at 5:25:50 PM UTC+8, José Valim wrote:
>
> Correct. My concern is someone having "@type one_of(X)" as an existing 
> type.
>
> On Sat, May 16, 2020 at 11:04 AM Wiebe-Marten Wijnja  > wrote:
>
>> I like the name `one_of` exactly because it is similar to what is in use 
>> by e.g. `StreamData` right now.
>>
>> If the construct is specific to Kernel.Typespec, then this would also 
>> limit conflicts with existing code, right?
>> On 16-05-2020 10:40, José Valim wrote:
>>
>> We wouldn't make it a macro per so, but a construct specific to 
>> Kernel.Typespec. It should be straight-forward. My biggest concern at this 
>> point is the name. :)
>>
>>
>> On Sat, May 16, 2020 at 10:21 AM Kip > 
>> wrote:
>>
>>> I had the `one_of` approach as my other alternative but figured adding 
>>> another function to Kernel (or elsewhere) may not be in favour. What do you 
>>> suggest I do next to progress this `one_of` idea as a poc? 
>>>
>>> Thanks too for the reduction, my attempts were making that far too 
>>> complicated!
>>>
>>> On Saturday, May 16, 2020 at 3:29:27 PM UTC+8, José Valim wrote: 
>>>>
>>>> Today you can do it like this:
>>>>
>>>> var = Enum.reduce(@list, &{:|, _. [&1, &2]}
>>>> @type foo :: unquote(var)
>>>>
>>>> But it may be worth introducing something like you describe but it 
>>>> probably makes sense to do it via a construct, such as @type foo :: 
>>>> one_of(@var) that does the conversion for you. I think automatically 
>>>> converting the list can be confusing, because people may think that [:foo, 
>>>> :bar] implies a specific ordering, for example.
>>>>
>>>> I am just not sure of a good name. one_of may conflict with existing 
>>>> code.
>>>>
>>>> On Sat, May 16, 2020 at 6:25 AM Kip  wrote:
>>>>
>>>>> It's not uncommon to have domain overlap between lists of valid tokens 
>>>>> (used for validations) and type specs. For example: 
>>>>>
>>>>>   @standard_formats [
>>>>> :standard,
>>>>> :accounting,
>>>>> :currency,
>>>>> :percent
>>>>>   ]
>>>>>
>>>>>   @currency_formats [
>>>>> :currency,
>>>>> :accounting,
>>>>> :currency_long,
>>>>> :currency_short
>>>>>   ]
>>>>>
>>>>>   @currency_symbol [
>>>>> :standard,
>>>>> :iso
>>>>>   ]
>>>>>
>>>>>   @type standard_formats :: :standard | :currency | :accounting | 
>>>>> :short | :long
>>>>>   @type currency_formats ::  :currency_short | :currency_long | 
>>>>> :decimal_short | :decimal_long
>>>>>   @type currency_symbol :: :standard | :iso
>>>>>
>>>>> It would go good to remove one source of error by being able to allow 
>>>>> compile time use of a list as the subject of  @typespec. For example:
>>>>>
>>>>> @type currency_symbol :: @currency_symbol # Any compile-time 
>>>>> resolvable list
>>>>>
>>>>> Of course a macro can be introduced to do this but its quite difficult 
>>>>> to achieve since it requires manual manipulation of AST.
>>>>>
>>>>> Proposal worth considering? Or consign to the history of my 
>>>>> less-than-helpful ideas :-)
>>>>>
>>>>>
>>>>> -- 
>>>>> 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-l...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/elixir-lang-core/36f821aa-d718-48aa-a9e8-2f6d5e440632%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/36f821aa-d718-48aa-a9e8-2f6d5e440632%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>&

[elixir-core:9511] [Proposal] Add String.normalize/2 for :nfkd and :nfkc

[Kip]

The Unicode compatibility (as apposed to canonical) composition is also 
implemented in the `:unicode` module and would be trivial to add to the 
`String.normalize/2` function. It would also complete the implementation of 
all normal forms defined by Unicode.  If this is a reasonable proposal I 
will happily send a PR.

-- 
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/dca7f0d6-e330-43b2-a0a7-6a1e2b1c9fa2%40googlegroups.com.

Re: [elixir-core:9504] Re: Add Turkish language support to things like `String.downcase/2` `String.upcase/2`.

[Kip]

Correct on both fronts José, I missed the language context. And yes 
September *2021* for Unicode 14.  I need to take a break, my accuracy is 
tracking too well today :-)

I just need to finished the code for Unicode regular expressions and the 
unicode transform rules engine so I can implement Unicode transforms. And 
then I'll feel like I can move on to something else other than I18n/L10n 
.

On Saturday, May 16, 2020 at 10:00:28 PM UTC+8, José Valim wrote:
>
> According to Unicode, both of those are context sensitive, which means we 
> can’t apply them like we apply the Greek rules.
>
> My understanding Is that Unicode 13 is out and we need to update it. 
> Unicode 14 will be out in September 2021.
>

-- 
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/1fb3d465-96e5-4f69-94ce-9cf7609efc88%40googlegroups.com.

[elixir-core:9502] Re: Add Turkish language support to things like `String.downcase/2` `String.upcase/2`.

[Kip]

Elixir supports the `:greek` mode for `String.upcase/2` and 
`String.downcase/2` backed by the data in `SpecialCasing.txt`.  It so 
happens that in Unicode 11 (the version upon which Elixir is based) only 
has the data for the Greek modality.

As of Unicode 13 (release in March) and perhaps Unicode 12 (I didn't 
check), SpecialCasing.txt also has the data to support an additional two 
modalities:

1. Turkic languages (Turkish and Azeri)
2. Lithuanian

Totally understand that full locale-customised transforms are outside the 
scope of Elixir (and are totally in scope for the work I'm doing with 
Unicode Transform algorithms). I do think a proposal to add these two 
variants has some merit since they are included in SpecialCasing.txt which 
is already part of Elixir's Unicode repertoire.

José, I know you have alway preferred to update the Unicode modules 
yourself. I'm still happy to give it a go.  Unicode 14 is going to be 
released on September 2020 which aligns nicely to Elixir 1.11.

Perhaps something to consider? Add Unicode 14 to Elixir 1.11 including 
supporting these two variants in SpecialCasing.txt as part of 
String.upcase/2 and String.downcase/2 as modes?

-- 
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/bfc8c779-ae03-4b5e-ab86-584aff3aafdd%40googlegroups.com.

Re: [elixir-core:9497] [Proposal] Support transforming lists to type specs

[Kip]

I had the `one_of` approach as my other alternative but figured adding 
another function to Kernel (or elsewhere) may not be in favour. What do you 
suggest I do next to progress this `one_of` idea as a poc?

Thanks too for the reduction, my attempts were making that far too 
complicated!

On Saturday, May 16, 2020 at 3:29:27 PM UTC+8, José Valim wrote:
>
> Today you can do it like this:
>
> var = Enum.reduce(@list, &{:|, _. [&1, &2]}
> @type foo :: unquote(var)
>
> But it may be worth introducing something like you describe but it 
> probably makes sense to do it via a construct, such as @type foo :: 
> one_of(@var) that does the conversion for you. I think automatically 
> converting the list can be confusing, because people may think that [:foo, 
> :bar] implies a specific ordering, for example.
>
> I am just not sure of a good name. one_of may conflict with existing code.
>
> On Sat, May 16, 2020 at 6:25 AM Kip > 
> wrote:
>
>> It's not uncommon to have domain overlap between lists of valid tokens 
>> (used for validations) and type specs. For example:
>>
>>   @standard_formats [
>> :standard,
>> :accounting,
>> :currency,
>> :percent
>>   ]
>>
>>   @currency_formats [
>> :currency,
>> :accounting,
>> :currency_long,
>> :currency_short
>>   ]
>>
>>   @currency_symbol [
>> :standard,
>> :iso
>>   ]
>>
>>   @type standard_formats :: :standard | :currency | :accounting | :short 
>> | :long
>>   @type currency_formats ::  :currency_short | :currency_long | 
>> :decimal_short | :decimal_long
>>   @type currency_symbol :: :standard | :iso
>>
>> It would go good to remove one source of error by being able to allow 
>> compile time use of a list as the subject of  @typespec. For example:
>>
>> @type currency_symbol :: @currency_symbol # Any compile-time resolvable 
>> list
>>
>> Of course a macro can be introduced to do this but its quite difficult to 
>> achieve since it requires manual manipulation of AST.
>>
>> Proposal worth considering? Or consign to the history of my 
>> less-than-helpful ideas :-)
>>
>>
>> -- 
>> 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-l...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/36f821aa-d718-48aa-a9e8-2f6d5e440632%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/elixir-lang-core/36f821aa-d718-48aa-a9e8-2f6d5e440632%40googlegroups.com?utm_medium=email_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/3577d145-b325-4c67-806c-d634df15ad5a%40googlegroups.com.

Re: [elixir-core:9496] Elixir 1.10-dev: adding transitive deps to mix.exs now a requirement?

[Kip]

In the library application https://github.com/elixir-cldr/cldr_units 
compiling on master produces

==> ex_cldr
Compiling 2 files (.erl)
Compiling 30 files (.ex)
warning: Cldr.Chars.List.__impl__/1 defined in application :ex_cldr_lists 
is used by the current application but the current application does not 
directly depend on :ex_cldr_lists. To fix this, you must do one of:

  1. If :ex_cldr_lists is part of Erlang/Elixir, you must include it under 
:extra_applications inside "def application" in your mix.exs

  2. If :ex_cldr_lists is a dependency, make sure it is listed under "def 
deps" in your mix.exs

  3. In case you don't want to add a requirement to :ex_cldr_lists, you may 
optionally skip this warning by adding [xref: [exclude: Cldr.Chars.List] to 
your "def project" in mix.exs

  lib/cldr/protocol/cldr_chars.ex:3: Cldr.Chars.impl_for/1

warning: Cldr.Chars.Float.__impl__/1 defined in application 
:ex_cldr_numbers is used by the current application but the current 
application does not directly depend on :ex_cldr_numbers. To fix this, you 
must do one of:

  1. If :ex_cldr_numbers is part of Erlang/Elixir, you must include it 
under :extra_applications inside "def application" in your mix.exs

  2. If :ex_cldr_numbers is a dependency, make sure it is listed under "def 
deps" in your mix.exs

  3. In case you don't want to add a requirement to :ex_cldr_numbers, you 
may optionally skip this warning by adding [xref: [exclude: 
Cldr.Chars.Float] to your "def project" in mix.exs

  lib/cldr/protocol/cldr_chars.ex:3: Cldr.Chars.impl_for/1

warning: Cldr.Chars.Integer.__impl__/1 defined in application 
:ex_cldr_numbers is used by the current application but the current 
application does not directly depend on :ex_cldr_numbers. To fix this, you 
must do one of:

  1. If :ex_cldr_numbers is part of Erlang/Elixir, you must include it 
under :extra_applications inside "def application" in your mix.exs

  2. If :ex_cldr_numbers is a dependency, make sure it is listed under "def 
deps" in your mix.exs

  3. In case you don't want to add a requirement to :ex_cldr_numbers, you 
may optionally skip this warning by adding [xref: [exclude: 
Cldr.Chars.Integer] to your "def project" in mix.exs

  lib/cldr/protocol/cldr_chars.ex:3: Cldr.Chars.impl_for/1

Generated ex_cldr app

The warning occurs for all the protocol implementations that are 
implemented in dependencies but the protocol itself is defined in `ex_cldr` 
and thats where the warning is emitted.

The mix.exs is:

  def application do
[
  extra_applications: [:logger]
]
  end

  defp deps do
[
  {:ex_cldr_numbers, "~> 2.13"},
  {:ex_cldr_lists, "~> 2.5"},
  
]
  end

As you can see, the warning relates to:

1. ex_cldr_numbers which is explicitly configured in deps and is not an otp 
app (has no `use Application`)
2. ex_cldr_lists which is explicitly configured in deps and is also not an 
otp app

Let me know if you'd prefer this logged as an issue?

-- 
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/d0809af0-9b0e-465b-863f-94c78562df4b%40googlegroups.com.

[elixir-core:9493] Elixir 1.10-dev: adding transitive deps to mix.exs now a requirement?

[Kip]

I notice on elixir master than a warning is now issued if transitive 
dependencies aren't directly configured in `mix.exs` and I'm curious as to 
the motivation and purpose.

-- 
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/3096188b-42de-414f-9cfd-3660e4964477%40googlegroups.com.

[elixir-core:9492] [Proposal] Support transforming lists to type specs

[Kip]

It's not uncommon to have domain overlap between lists of valid tokens 
(used for validations) and type specs. For example:

  @standard_formats [
:standard,
:accounting,
:currency,
:percent
  ]

  @currency_formats [
:currency,
:accounting,
:currency_long,
:currency_short
  ]

  @currency_symbol [
:standard,
:iso
  ]

  @type standard_formats :: :standard | :currency | :accounting | :short | 
:long
  @type currency_formats ::  :currency_short | :currency_long | 
:decimal_short | :decimal_long
  @type currency_symbol :: :standard | :iso

It would go good to remove one source of error by being able to allow 
compile time use of a list as the subject of  @typespec. For example:

@type currency_symbol :: @currency_symbol # Any compile-time resolvable list

Of course a macro can be introduced to do this but its quite difficult to 
achieve since it requires manual manipulation of AST.

Proposal worth considering? Or consign to the history of my 
less-than-helpful ideas :-)


-- 
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/36f821aa-d718-48aa-a9e8-2f6d5e440632%40googlegroups.com.

[elixir-core:7930] [Proposal] Calendar callback months_in_year/1

[Kip]

I'm back working on calendar-related functions.  I'd like to propose an 
addition to the Calendar behaviour:

@callback months_in_year(year) :: month

Which returns the number of months in a year.  An example use I'm currently 
work on is subscriptions.  I bill monthly and therefore want to calculate 
"next month".  I can increment month in {year, month, day} but then I need 
to know what the modulo is.

Not all calendars have 12 months.  The Hebrew calendar, for example, has 13 
months in a leap year.  The balinese saka calendar has a similar 
intercalary month added from time-to-time.

I accepted I will craft a PR for this for Calendar, Calendar.ISO and tests.

--Kip

-- 
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/812c799c-cf39-45cc-a202-6953bea3a496%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elixir-core:7285] Re: [Proposal] Calendar behaviour additions to support localisation libraries and other calendar calculations

[Kip]

@jose, @Qqwy,

I am prototyping some of these implementation details in the next release 
of my CLDR work.  The nature of a week is indeed a complex beast.  But 
since José was smart enough to pick ISO calendar as the Elixir 
implementation the definition of "first week" seems clear.  The first week 
is that in which the first Thursday falls. (or is the that week with at 
least 4 days of the new year).

Before I get too far may I ask if this is in agreement?  The reference I am 
using is https://en.wikipedia.org/wiki/ISO_week_date#First_week with the 
suggest calculations 
being https://en.wikipedia.org/wiki/ISO_week_date#Calculation

For other calendars the definition of "first week" is/may be territory 
specific.  As is "first day" and "weekday". Which is why localisation is 
such fun ..

--Kip

On Tuesday, July 11, 2017 at 3:53:36 PM UTC+2, Wiebe-Marten Wijnja wrote:
>
> Yes, I think those arguments are arguments for allowing weeks to be 
> specified in their own calendar implementations, treating weeks like months.
> I'd think Elixir itself should then implement the ISO week date calendar, 
> and locale-specific week logic can be put in locale-specific calendar 
> implementation modules. This would also keep the door open for "4-5-4" and 
> friends-based weeks, 10-day based weeks, etc.
> Counting in weeks definitely has the same amount of complexity as counting 
> in months in a normal calendar (I am talking about odd leaping rules here), 
> so it definitely makes sense to use the same or a similar interface for 
> this.
>
> The question then remains to how to make this more user-friendly. Maybe we 
> can add functions on the `Date`-module that take an optional 
> `week_calendar: Calendar.Implementation` as last parameter, that underwater 
> does:
>
> 1. Take the Date-struct, and convert it to the given Calendar. (failing as 
> usual if the conversion is not possible because of incompatible calendars)
> 2. Perform calculations on the resulting struct using the existing 
> Calendar implementation functions, where the 'months' are weeks.
> 3. Return the desired answer.
>
>
> On Monday, July 10, 2017 at 11:48:26 PM UTC+2, Kip wrote:
>>
>> Definitely worth thinking about as an approach for weeks. Some of 
>> calendars may make that tricky - I'll need to ponder some more.
>>
>> 1.   "4-5-4" calendar (and its related friends 445 and 544).  This is 
>> used extensively by the retail industry (
>> https://nrf.com/resources/4-5-4-calendar).
>>
>> 2.  Another class is the financial period calendars of corporations in 
>> the US that get to define their fiscal year.  For example Cisco Inc has a 
>> financial year defined as "ends of the last Saturday of July".  Its fiscal 
>> year 2017 for example, starts on July 31st 2016. (also to note the 
>> effective year is different from the gregorian year of the day in 
>> question).  This is a class of calendar that requires configuration 
>> information - I haven't quite worked out the right strategy for these 
>> calendars yet (Date.new/3 won't fit these cases as is)
>>
>> Then there is the locale-specific understanding of a week:
>>
>> 1.  Starts on a Monday, Saturday or Sunday
>>
>> 2.  1st week starts as the first calendar week which contains four days 
>> of the new year
>>
>> 3.  1st week starts as the week in which January 1st occurs
>>
>> I think these situations are likely to make basing weeks along the ISO 
>> Week strategy a bit tricky.
>>
>> On Tuesday, July 11, 2017 at 5:15:37 AM UTC+8, Wiebe-Marten Wijnja wrote:
>>>
>>> I am all for this!
>>>
>>> However, I do have a note about the week-related stuff: 
>>> On one hand, people might expect 'weeks' to be readily available 
>>> (`:calendar` offers them, and many other libraries in other language 
>>> environments do). 
>>> On the other, many calendars do not themselves have a notion of weeks. 
>>> (Weeks are only secondary units of date measurements (years, months, days 
>>> are the primary ones) and nearly all calendars, all across the globe, use a 
>>> seven-day week.
>>> Weeks are basically the months of the ISO week date calendar: 
>>> https://en.wikipedia.org/wiki/ISO_week_date
>>> I wonder how much of the week-related functionality could be defined by 
>>> just taking a date (in e.g. Calendar.ISO) and converting it into the ISO 
>>> week date calendar. 
>>>
>>> ~Qqwy/Wiebe-Marten
>>>
>>>
>>> On Monday, July 10, 2017 at 9:03:53 AM UTC+2, Kip wrote:
>>>>
>>>>

[elixir-core:7259] [Proposal] Calendar behaviour additions to support localisation libraries and other calendar calculations

[Kip]

With the new capabilities of Calendar in 1.5 I am now adding date and time 
localisation to a package I maintain (https://hex.pm/packages/ex_cldr).  

CLDR (http://unicode.org/reports/tr35/tr35-dates.html#Date_Format_Patterns) 
defines a number of symbols to aid formatting and localisation.  Many of 
these can be supported by the Calendar module (or easily derived).  Some 
would be better defined in a calendar module - which would imply adding 
them to the behaviour and to Calendar.ISO.

These functions are:

1. months_in_year(year) which together with the existing days_in_month/2 
would allow the calculation of quarters which is relevant in a lot of 
business contexts
2. week_of_year(date) which returns the week number within which the date 
occurs.  
3. week_of_month(date) which returns the week of the month within which the 
date occurs
5. day_of_week_in_month(date) returns the ordinal day (i.e. 2nd in 2nd 
Wednesday in July)
6. year(date) which returns the effective year in which the date lies.  For 
example in an ISO Week implementation, the "year" may be different to the 
"year in the date"

Although my immediate focus is date formatting and localisation, these 
functions are of themselves relevant for other "calendarists" (is that a 
word?)   Each of these may have quite specific implementation details 
related to a given calendar and therefore would seem to be appropriate to 
be part of the behaviour. 

I've tried to think of only those functions which cannot be readily derived 
without knowledge of the specific calendar but I know this is a slippery 
slope - especially with anything to do with time and dates.

Thoughts?

--Kip

-- 
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/20060086-74b8-4a40-bbf4-a160783f94d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6790] Re: Introducing Calendar types

[Kip Cole]

José, it seems appropriate to post a PR for Calendar on the first day of the 
year :-)  https://github.com/elixir-lang/elixir/pull/5603 
<https://github.com/elixir-lang/elixir/pull/5603>

This embodies the idea of a canonical integer date representation.  I have used 
the principles embodied in Calendrical Calculations by Dershowitz and Rheingold 
since I think that provides a very solid and well-proven basis for calendar 
creators.  I added a Calendar.Julian as one example.

I took the opportunity to add support for DateRange and the Enum protocol, a 
Date.diff/2 function and the standard set of kday functions.

Happy New Year to all.

> On 30 Dec. 2016, at 1:03 am, José Valim <jose.va...@plataformatec.com.br> 
> wrote:
> 
> > With the guidance from José in this thread I can finish up development now 
> > and see if the community thinks its worth a PR.  Of course calendars beyond 
> > the standard ISO would be a separate package(s) and any changes will have 
> > to have the same or better performance profile and pass all current tests 
> > too.
> 
> A bit delayed on my reply but I would love to see what you come up with. Let 
> me know if there is anything else I can help with.
> 
> 
> 
> José Valim
> www.plataformatec.com.br <http://www.plataformatec.com.br/>
> Skype: jv.ptec
> Founder and Director of R
> 
> On Tue, Dec 20, 2016 at 2:14 AM, Kip Cole <kipco...@gmail.com 
> <mailto:kipco...@gmail.com>> wrote:
> José, Paul, thanks both.
> 
> José: option (b) would seem better to me as well - and it means my work is 
> not (yet?) in vain :-)
> 
> Paul: I’m working on calendrical calculations for Elixir and want to be 
> Calendar behaviour compatible.I think some small and compatible 
> adjustments to Date and DateTime/NaiveDateTime can allow all of the calendars 
> in Calendrical Calculations to be developed in accordance with the behaviour 
> except those that don’t reduce to a {y, m, d} tuple - like the  Balinese 
> calendar.  Including Date.to_fixed() would be a necessary part of that as a 
> way of allowing date comparisons and calendar conversions.  Which can be done 
> with no performance impact to Calendar. ISO I believe.
> 
> With the guidance from José in this thread I can finish up development now 
> and see if the community thinks its worth a PR.  Of course calendars beyond 
> the standard ISO would be a separate package(s) and any changes will have to 
> have the same or better performance profile and pass all current tests too.
> 
> Perhaps its a quirk, but I happen to really like calendar stuff - its the 
> relationship to human history I think.
> 
> 
> Oh, and I’m not proposing the 
>> On 20 Dec 2016, at 9:51 AM, Paul Schoenfelder <paulschoenfel...@gmail.com 
>> <mailto:paulschoenfel...@gmail.com>> wrote:
>> 
>> I think a good approach would be to define a reference date, from which all 
>> calendars can use as a point to convert to and from. This method is used in 
>> the book Calendrical Calculations, and their associated Java/Scheme 
>> implementation called Calendrica (which includes Egyptian/Armenian, 
>> Gregorian, Julian, Coptic/Ethiopic, ISO, Islamic, Hebrew, Ecclesiastical, 
>> Hindu, Mayan, Balinese Pawukon, Persian, French Revolutionary, and Chinese 
>> calendars). It works by defining a "fixed" calendar, which starts with day 
>> 1, and then defining conversions to and from the "fixed" calendar by using 
>> the number of days relative to that calendar. In Calendrica, the start of 
>> "fixed" date 1 is the same as the start of the Gregorian (proleptic) 
>> calendar, e.g. midnight of January 1st, year 1, thus to_fixed({1,1,1}) == 1. 
>> Since the passage of time can be represented as days -1, 0, 1, 2, ..N 
>> relative to the fixed calendar, this provides a way to convert between any 
>> set of calendars, by simply converting to the fixed calendar, and then 
>> converting to the destination calendar. Time is similarly treated, as each 
>> calendar also defines the point in time at which a day "starts", so 
>> conversions are all unified to occur at noon. Since in many calendars this 
>> is based on location, it is up to the calendar implementation to convert to 
>> noon prior to doing conversions to another calendar. There is a great deal 
>> more that goes into it, but hopefully it at least sparks some discussion 
>> about how to approach this. In my opinion, it's the best approach I've come 
>> across so far (and I wouldn't be surprised if it's effectively the only 
>> workable approach).
>> 
>> Paul
>> 
>> On Mon, Dec 19, 2016 at 4:32 PM, José Valim <jose.va...@platafor

Re: [elixir-core:6754] Re: Introducing Calendar types

[Kip Cole]

José, Paul, thanks both.

José: option (b) would seem better to me as well - and it means my work is not 
(yet?) in vain :-)

Paul: I’m working on calendrical calculations for Elixir and want to be 
Calendar behaviour compatible.I think some small and compatible adjustments 
to Date and DateTime/NaiveDateTime can allow all of the calendars in 
Calendrical Calculations to be developed in accordance with the behaviour 
except those that don’t reduce to a {y, m, d} tuple - like the  Balinese 
calendar.  Including Date.to_fixed() would be a necessary part of that as a way 
of allowing date comparisons and calendar conversions.  Which can be done with 
no performance impact to Calendar. ISO I believe.

With the guidance from José in this thread I can finish up development now and 
see if the community thinks its worth a PR.  Of course calendars beyond the 
standard ISO would be a separate package(s) and any changes will have to have 
the same or better performance profile and pass all current tests too.

Perhaps its a quirk, but I happen to really like calendar stuff - its the 
relationship to human history I think.


Oh, and I’m not proposing the 
> On 20 Dec 2016, at 9:51 AM, Paul Schoenfelder  
> wrote:
> 
> I think a good approach would be to define a reference date, from which all 
> calendars can use as a point to convert to and from. This method is used in 
> the book Calendrical Calculations, and their associated Java/Scheme 
> implementation called Calendrica (which includes Egyptian/Armenian, 
> Gregorian, Julian, Coptic/Ethiopic, ISO, Islamic, Hebrew, Ecclesiastical, 
> Hindu, Mayan, Balinese Pawukon, Persian, French Revolutionary, and Chinese 
> calendars). It works by defining a "fixed" calendar, which starts with day 1, 
> and then defining conversions to and from the "fixed" calendar by using the 
> number of days relative to that calendar. In Calendrica, the start of "fixed" 
> date 1 is the same as the start of the Gregorian (proleptic) calendar, e.g. 
> midnight of January 1st, year 1, thus to_fixed({1,1,1}) == 1. Since the 
> passage of time can be represented as days -1, 0, 1, 2, ..N relative to the 
> fixed calendar, this provides a way to convert between any set of calendars, 
> by simply converting to the fixed calendar, and then converting to the 
> destination calendar. Time is similarly treated, as each calendar also 
> defines the point in time at which a day "starts", so conversions are all 
> unified to occur at noon. Since in many calendars this is based on location, 
> it is up to the calendar implementation to convert to noon prior to doing 
> conversions to another calendar. There is a great deal more that goes into 
> it, but hopefully it at least sparks some discussion about how to approach 
> this. In my opinion, it's the best approach I've come across so far (and I 
> wouldn't be surprised if it's effectively the only workable approach).
> 
> Paul
> 
> On Mon, Dec 19, 2016 at 4:32 PM, José Valim  > wrote:
> It is option B.
> 
> If we don't delegate to the calendar implementation, we always hardcode to 
> Calendar.ISO. This way users of other calendars get a hard failure and we can 
> discuss how to best move forward. So if you look at the "to_erl" 
> implementation, you will see that it only supports Calendar.ISO.
> 
> This means it is time to have the conversation. :) We have two options:
> 
> 1. Make "to_erl" part of the calendar behaviour. However, since the Erlang 
> representation is a Proleptic Gregorian calendar, to_erl would effectively be 
> a conversion to gregorian.
> 
> 2. Make date_compare and naive_date_time_compare part of the calendar 
> behaviour.
> 
> One question you may know the answer: are calendar conversions bijective? For 
> example, is a date in one calendar guaranteed to represent a single date in 
> another calendar and vice-versa? I would think that yes, because of time, but 
> never underestimate calendars. But if yes, we could convert dates to a known 
> calendar (Proleptic Gregorian) and then compare them (solution 1). This would 
> also allow comparisons between calendars (which again, requires them to be 
> bijective).
> 
> 
> -- 
> 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/CAGnRm4J_wV%3DtzXdjUubrYpi_fgPOSa39eG0CAwa0y3F3oMvGGw%40mail.gmail.com
>  
> .
> 
> For more options, visit https://groups.google.com/d/optout 
> 

Re: [elixir-core:6750] Re: Introducing Calendar types

[Kip Cole]

Thanks for the food for thought José.  The Calendar.define() approach sounds 
much better than passing a meta payload around.  In some cases I can see 
compile time benefit, others cases would need runtime definition but that's 
workable since it still would be defined only once.

I'm going to finish up some code I've been working on and incorporate the 
Calendar.define() strategy (I'll experiment with both approaches) and see if 
that would be worth a PR down the road.

> On 19 Dec 2016, at 9:21 PM, José Valim  
> wrote:
> 
> 
>> This is even a small ambiguity in an ISO calendar since the question of 
>> “first day of the year” depends on whether you mean the first day of the 
>> first week, or the first day of January.
> 
> ISO8601 defines three representations: Calendar date, ordinal date and week 
> dates. We could explicitly document we are implementing the first format.
> 
>> But if your calendar starts on “first thursday of april” then the last day 
>> can only really be encoded as {m, y} in the gregorian calendar because the 
>> notion of a month in this calendar does not align with a gregorian month 
>> boundary.  I suppose that if the definition of `last_day_of_month` was 
>> changed to mean “number of days in a month” then this type of calendar could 
>> be implemented without change and still be compliant with the calendar 
>> behaviour.
> 
> If you have a calendar where the first month starts on "first thursday of 
> April" and finishes the first month on the "first wednesday of May" such 
> calendar still has a notion of months. In a leap week calendar they would all 
> have 28 days with the exception of a month with a leap week (which would have 
> 35).
> 
> Writing the paragraph above also made it absolutely clear that you are indeed 
> correct: days_in_month/2 is a better name than last_day_of_month/2. Since 
> last_day_of_month/2 was not yet released (only in RCs), I will go ahead and 
> rename it.
> 
> On the other hand, You could also have week-based calendars that have no 
> notion of months and therefore last_day_of_month or days_in_month have no 
> purpose. Those probably wouldn't be representable with Elixir's calendar 
> types.
>  
>> But I would still need some way to define configuration.  How do I capture 
>> that my version of Calendar.FiscalYear starts on July 1st, and another one 
>> starts on April 1st.  All other rules are the same - just a different start 
>> date.
> 
> Calendar modules are backends that power DateTime, Date, and NaiveDateTime. 
> This means you could have a function such as:
> 
> FiscalYear.define(MyApp.AprilCalendar, starts_at: "foo", ends_at: "bar")
> 
> The above would define a module named MyApp.AprilCalendar that implements all 
> of the Calendar behaviour functions. It works similarly to the metadata you 
> have mentioned, except such parameters are defined at compilation time, 
> rather than runtime.
> 
> However, it is still not clear if the above would be the preferred solution 
> to the problem. I am still partially inclined to think having a FiscalYear 
> module that works orthogonally to the ISO calendar would work best. In such 
> approach, you would have:
> 
> FiscalYear.define(MyApp.AprilBased, starts_at: "foo", ends_at: "bar")
> 
> That would define a module mirroring many of the functions in Date/DateTime 
> except they do fiscal year related manipulations. For example, you could have 
> Date.beginning_of_next_month(date) and 
> MyApp.AprilBased.beginning_of_next_month(date) and they would return 
> different results. The benefit is that you keep the data representation the 
> same and choose how you want to manipulate it.
> 
> Do you have any preferences?
>  
>> I think the idea of representing a date as a {y, m, d} is effectively an 
>> encoding mechanism that happens to be the same as the proleptic Gregorian 
>> calendar - a case which matches the calendar in use by a lot of people 
>> thereby making it convenient and easy and I’m not proposing any alternative 
>> to that.
> 
> Yes, we have discussed both y/m/d and second based and the consensus was 
> around {y, m, d} due to conversion cost and pattern matching benefits.
> 
> Thanks for the e-mails!
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "elixir-lang-core" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/elixir-lang-core/KvJQaUcUlOk/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAGnRm4JzQOf2F-sO%2BZy4dYo%2Bn-UqOph7eer5dpLqD9TxJ8brPA%40mail.gmail.com.
> 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