Think of it this way:

Elm is a Web language. It compiles to JS, because right now that is the
only way to get at the web. But we're not a JS framework, we're not a JS
addon. We're a full, independent language, and JS is just a means to an
end. Come the days of WebAssembly or something better, we will probably
move to something better.

Using JS in Elm right now is like using Assembly in a C program. Sure, you
*could* just use existing assembly libraries, but they hurt your
portability in the long run, they're harder to debug, and they lose lots of
safety checks.

Elm is in the process of using less, not more, JS in its core, so changes
to the contrary are less likely to be accepted.

On Sun, Jun 19, 2016 at 11:36 PM, Ian Mackenzie <[email protected]>
wrote:

> 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.
>

-- 
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.

Reply via email to