I think one other thing to keep in mind is that Evan has expressed a lot of interest in other (non-JavaScript) compilation targets in the future, so I think he would be very cautious about tying core library functionality too closely to exactly how JavaScript happens to do things. Especially for stuff like date/time manipulation which (correct me if I'm wrong) is unlikely to be a performance bottleneck, I think the best long-term solution is going to be a well thought out pure-Elm library using common Elm patterns and idioms - which would probably look very different than a direct wrapper over JavaScript. Perhaps that is something that will be implemented as a core library at some point, but right now I'd imagine a lot of other things are a higher priority.
On Monday, 20 June 2016 08:00:00 UTC+10, Dan P wrote: > > I appreciate the immutability part, but we can make these setters into > pure functions by creating new Date objects with each call. > > Secondly, when you're rewriting pure functions provided by the JS API > itself, the only thing you do is increase the chance of an implementation > mistake. The only thing that isn't totally uniform across browsers is > Date.parseString(). There are things that can be improved, like how Haskell > uses types to distinguish UTCTime and LocalTime, but don't fix what ain't > broke. > > > On Sunday, June 19, 2016 at 5:37:15 PM UTC-4, Joey Eremondi wrote: >> >> reproduces working JS APIs >> >> >> This is the goal! Reproducing libraries in pure Elm is much safer and >> more desirable than writing wrappers around JS. >> >> Make sure that whatever you do, you respect Elm's philosophy: all data is >> immutable, and side-effects are always wrapped in a Task or a Cmd. >> >> On Sun, Jun 19, 2016 at 1:31 PM, Dan P <[email protected]> wrote: >> >>> I realize elm-date-extra <https://github.com/rluiten/elm-date-extra> >>> exists, >>> but it's bloated, (apparently) unstable, reproduces working JS APIs, and is >>> not likely to be merged to core any time soon[1]. I'm considering making a >>> simplified fork of the former, but this rejected pull request >>> <https://github.com/elm-lang/core/pull/214> gives me pause. Can anyone >>> more familiar with the Elm ecosystem please advise? >>> >>> [1]: Not to say that it doesn't also provide useful functionality! But >>> core.Date is a little spartan, don't you think? >>> >>> >>> >>> On Sunday, June 19, 2016 at 3:03:51 PM UTC-4, Dan P wrote: >>>> >>>> (e.g. Date.setDate() in JS) >>>> >>>> Or would a pull request not be in vain? >>>> >>>> Compare: >>>> http://package.elm-lang.org/packages/elm-lang/core/4.0.1/Date >>>> >>>> >>>> https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Date >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Elm Discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
