In the meantime 0.18 has been a very productive language.
One thing to understand is Evan wants Elm to be a language and not bound to JavaScript. This is the sound motivation behind blocking native packages.
In the meantime 0.18 has been a very productive language.
One thing to understand is Evan wants Elm to be a language and not bound to JavaScript. This is the sound motivation behind blocking native packages.
Useful languages can interop with other languages.
Elm 0.18 and below (not sure what 0.19 is doing, it's not released) has synchronous interop through native modules, but those have been discouraged and documented as "do not use, will change in the future" since the beginning. And you can't easily publish them to the package repository.
To say Elm doesn't interop with Javascript is just wrong.
You may disagree with Elm's stance on its synchronous interop, but you're just disagreeing with trade-offs. Like all trade-offs, just because someone chose different ones than you doesn't mean they were oblivious to them.
'One thing to understand is Evan wants Elm to be a language and not bound to JavaScript.'
is a good explanation (or a 'sound motivation') for the current design decision. Thank you for expanding on the goals of the current design. People less familiar with Elm, such as myself, have learned something about Elm's capabilities and strategies for dealing with interop.
callJS :: JSFunction -> (JSObject | JSException)
Or however you spell it in Elm.
Admittedly, if Elm is lazy like Haskell, you need some way to deal with the fact that Javascript functions are impure.