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 <dply...@gmail.com> 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 elm-discuss...@googlegroups.com. >>> 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
