Re: [elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

[Mark Hamburg]

Specifically to support MessagePack it seems like Elm needs:

1. Support for binary data — even if just as a blob that it can pass around
but not inspect. There are references to blobs in places like the Http
module but this appears to have been consigned to the backburner.

2. Support for binary places in the places you actually need it — e.g., web
sockets and Http.

3. Task based interfaces for web sockets if that's where it is being used —
or a sense that using WebSocket.LowLevel is as blessed as using WebSocket.
This is needed to support composition.

4. Task ports so that one could wire up existing JavaScript message pack
libraries.

In other words, Elm COULD support MessagePack without lots of binary
manipulation support and a port of MessagePack to Elm — though obviously
that might be preferable if performance didn't suffer — but it hinges on a
bunch of edges that feel awkward or neglected in Elm right now.

Mark

On Mon, Mar 27, 2017 at 4:20 PM, Kasey Speakman 
wrote:

> But compared to other compile-to-js languages, Elm is seemingly the one
>> that puts the most the hurdles ahead of easily using the libraries
>> available in the world's most popular language.
>
>
> You are correct. Elm is harder to interop than most other compile-to-js
> platforms. That's because Elm tries to guarantee that all user code is pure
> (as in pure functions). This makes Elm apps continue to be evolvable and
> refactorable despite adding new features. Using native code throws away
> Elm's guarantees, so it is discouraged. Using ports (the blessed way to
> interop) maintains the guarantees at the border, but it has trade-offs as
> you've noted in the original post.
>
> Unfortunately, interop is a hard problem to solve while keeping Elm's
> benefits intact. WIP.
>
> On Sunday, March 26, 2017 at 2:57:11 PM UTC-5, Simon wrote:
>>
>> Ok, I hope that this is just a naming change, but spent too much time in
>> politics not to fixate on choice of language issues!
>> But compared to other compile-to-js languages, Elm is seemingly the one
>> that puts the most the hurdles ahead of easily using the libraries
>> available in the world's most popular language.
>>
>>
>>
>> On Saturday, 25 March 2017 02:52:20 UTC+1, Kasey Speakman wrote:
>>>
>>> Yeah, I regretted posting that 2nd half. I don't use any native modules
>>> myself except the one to return decoders out of ports. And I was getting by
>>> without it via ports, although somewhat less optimally. Maybe some people
>>> really need native stuff, though. I haven't. (And I'm willing to monkey
>>> patch what I use native for now if need be.)
>>>
>>> On Friday, March 24, 2017 at 1:48:01 PM UTC-5, Kasey Speakman wrote:

 Indeed, the post mentions renaming Native to Elm.Kernel and ending the
 native module whitelist (sortof). Expectation management.

 User native module blocking was not mentioned. In our current
 Javascript ecosystem such a thing would make Elm non-viable.

 Well, except that repo-forking and monkey-patching exist.

 On Friday, March 24, 2017 at 6:42:34 AM UTC-5, Rupert Smith wrote:
>
> On Thursday, March 23, 2017 at 8:15:51 PM UTC, Simon wrote:
>>
>> It's pretty clear that these practices are frowned upon, but the
>> shift to 'kernel' sounds like a plan to squeeze the pragmatic 
>> programmer's
>> options further. I hope that's not the case.
>>
>
> I think all that is happening is that Native is being renamed to
> Kernel to reduce confusion. At the moment when we say 'Elm' and 'native' 
> in
> the same sentence we could mean an Elm Native module used to implement its
> kernel, or native javascript code through ports.
>
> I can't be certain of the details but I think your function would just
> be re-written as:
>
> var _user$project$Kernel_Msgpack = function() { ... }
>
> But you won't be able to publish it officially and will have to use
> elm-github-install.
>
> It makes sense to me anyway, the 'kernel' needs to be carefully
> managed as the language takes shape.
>
> --
> 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.
>

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

[elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

[Kasey Speakman]

>
> But compared to other compile-to-js languages, Elm is seemingly the one 
> that puts the most the hurdles ahead of easily using the libraries 
> available in the world's most popular language.


You are correct. Elm is harder to interop than most other compile-to-js 
platforms. That's because Elm tries to guarantee that all user code is pure 
(as in pure functions). This makes Elm apps continue to be evolvable and 
refactorable despite adding new features. Using native code throws away 
Elm's guarantees, so it is discouraged. Using ports (the blessed way to 
interop) maintains the guarantees at the border, but it has trade-offs as 
you've noted in the original post.

Unfortunately, interop is a hard problem to solve while keeping Elm's 
benefits intact. WIP.

On Sunday, March 26, 2017 at 2:57:11 PM UTC-5, Simon wrote:
>
> Ok, I hope that this is just a naming change, but spent too much time in 
> politics not to fixate on choice of language issues!
> But compared to other compile-to-js languages, Elm is seemingly the one 
> that puts the most the hurdles ahead of easily using the libraries 
> available in the world's most popular language.
>
>
>
> On Saturday, 25 March 2017 02:52:20 UTC+1, Kasey Speakman wrote:
>>
>> Yeah, I regretted posting that 2nd half. I don't use any native modules 
>> myself except the one to return decoders out of ports. And I was getting by 
>> without it via ports, although somewhat less optimally. Maybe some people 
>> really need native stuff, though. I haven't. (And I'm willing to monkey 
>> patch what I use native for now if need be.)
>>
>> On Friday, March 24, 2017 at 1:48:01 PM UTC-5, Kasey Speakman wrote:
>>>
>>> Indeed, the post mentions renaming Native to Elm.Kernel and ending the 
>>> native module whitelist (sortof). Expectation management.
>>>
>>> User native module blocking was not mentioned. In our current Javascript 
>>> ecosystem such a thing would make Elm non-viable.
>>>
>>> Well, except that repo-forking and monkey-patching exist.
>>>
>>> On Friday, March 24, 2017 at 6:42:34 AM UTC-5, Rupert Smith wrote:

 On Thursday, March 23, 2017 at 8:15:51 PM UTC, Simon wrote:
>
> It's pretty clear that these practices are frowned upon, but the shift 
> to 'kernel' sounds like a plan to squeeze the pragmatic programmer's 
> options further. I hope that's not the case.
>

 I think all that is happening is that Native is being renamed to Kernel 
 to reduce confusion. At the moment when we say 'Elm' and 'native' in the 
 same sentence we could mean an Elm Native module used to implement its 
 kernel, or native javascript code through ports.

 I can't be certain of the details but I think your function would just 
 be re-written as:

 var _user$project$Kernel_Msgpack = function() { ... }

 But you won't be able to publish it officially and will have to use 
 elm-github-install.

 It makes sense to me anyway, the 'kernel' needs to be carefully managed 
 as the language takes shape.



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

[elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

['Rupert Smith' via Elm Discuss]

On Sunday, March 26, 2017 at 8:57:11 PM UTC+1, Simon wrote:
>
> But compared to other compile-to-js languages, Elm is seemingly the one 
> that puts the most the hurdles ahead of easily using the libraries 
> available in the world's most popular language.
>

That would be Java: 

https://www.tiobe.com/tiobe-index/ 

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

[elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

[Simon]

Ok, I hope that this is just a naming change, but spent too much time in 
politics not to fixate on choice of language issues!
But compared to other compile-to-js languages, Elm is seemingly the one 
that puts the most the hurdles ahead of easily using the libraries 
available in the world's most popular language.



On Saturday, 25 March 2017 02:52:20 UTC+1, Kasey Speakman wrote:
>
> Yeah, I regretted posting that 2nd half. I don't use any native modules 
> myself except the one to return decoders out of ports. And I was getting by 
> without it via ports, although somewhat less optimally. Maybe some people 
> really need native stuff, though. I haven't. (And I'm willing to monkey 
> patch what I use native for now if need be.)
>
> On Friday, March 24, 2017 at 1:48:01 PM UTC-5, Kasey Speakman wrote:
>>
>> Indeed, the post mentions renaming Native to Elm.Kernel and ending the 
>> native module whitelist (sortof). Expectation management.
>>
>> User native module blocking was not mentioned. In our current Javascript 
>> ecosystem such a thing would make Elm non-viable.
>>
>> Well, except that repo-forking and monkey-patching exist.
>>
>> On Friday, March 24, 2017 at 6:42:34 AM UTC-5, Rupert Smith wrote:
>>>
>>> On Thursday, March 23, 2017 at 8:15:51 PM UTC, Simon wrote:

 It's pretty clear that these practices are frowned upon, but the shift 
 to 'kernel' sounds like a plan to squeeze the pragmatic programmer's 
 options further. I hope that's not the case.

>>>
>>> I think all that is happening is that Native is being renamed to Kernel 
>>> to reduce confusion. At the moment when we say 'Elm' and 'native' in the 
>>> same sentence we could mean an Elm Native module used to implement its 
>>> kernel, or native javascript code through ports.
>>>
>>> I can't be certain of the details but I think your function would just 
>>> be re-written as:
>>>
>>> var _user$project$Kernel_Msgpack = function() { ... }
>>>
>>> But you won't be able to publish it officially and will have to use 
>>> elm-github-install.
>>>
>>> It makes sense to me anyway, the 'kernel' needs to be carefully managed 
>>> as the language takes shape.
>>>
>>>

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

[elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

[Kasey Speakman]

Yeah, I regretted posting that 2nd half. I don't use any native modules 
myself except the one to return decoders out of ports. And I was getting by 
without it via ports, although somewhat less optimally. Maybe some people 
really need native stuff, though. I haven't. (And I'm willing to monkey 
patch what I use native for now if need be.)

On Friday, March 24, 2017 at 1:48:01 PM UTC-5, Kasey Speakman wrote:
>
> Indeed, the post mentions renaming Native to Elm.Kernel and ending the 
> native module whitelist (sortof). Expectation management.
>
> User native module blocking was not mentioned. In our current Javascript 
> ecosystem such a thing would make Elm non-viable.
>
> Well, except that repo-forking and monkey-patching exist.
>
> On Friday, March 24, 2017 at 6:42:34 AM UTC-5, Rupert Smith wrote:
>>
>> On Thursday, March 23, 2017 at 8:15:51 PM UTC, Simon wrote:
>>>
>>> It's pretty clear that these practices are frowned upon, but the shift 
>>> to 'kernel' sounds like a plan to squeeze the pragmatic programmer's 
>>> options further. I hope that's not the case.
>>>
>>
>> I think all that is happening is that Native is being renamed to Kernel 
>> to reduce confusion. At the moment when we say 'Elm' and 'native' in the 
>> same sentence we could mean an Elm Native module used to implement its 
>> kernel, or native javascript code through ports.
>>
>> I can't be certain of the details but I think your function would just be 
>> re-written as:
>>
>> var _user$project$Kernel_Msgpack = function() { ... }
>>
>> But you won't be able to publish it officially and will have to use 
>> elm-github-install.
>>
>> It makes sense to me anyway, the 'kernel' needs to be carefully managed 
>> as the language takes shape.
>>
>>

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

[elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

[Kasey Speakman]

Indeed, the post mentions renaming Native to Elm.Kernel and ending the 
native module whitelist (sortof). Expectation management.

User native module blocking was not mentioned. In our current Javascript 
ecosystem such a thing would make Elm non-viable.

Well, except that repo-forking and monkey-patching exist.

On Friday, March 24, 2017 at 6:42:34 AM UTC-5, Rupert Smith wrote:
>
> On Thursday, March 23, 2017 at 8:15:51 PM UTC, Simon wrote:
>>
>> It's pretty clear that these practices are frowned upon, but the shift to 
>> 'kernel' sounds like a plan to squeeze the pragmatic programmer's options 
>> further. I hope that's not the case.
>>
>
> I think all that is happening is that Native is being renamed to Kernel to 
> reduce confusion. At the moment when we say 'Elm' and 'native' in the same 
> sentence we could mean an Elm Native module used to implement its kernel, 
> or native javascript code through ports.
>
> I can't be certain of the details but I think your function would just be 
> re-written as:
>
> var _user$project$Kernel_Msgpack = function() { ... }
>
> But you won't be able to publish it officially and will have to use 
> elm-github-install.
>
> It makes sense to me anyway, the 'kernel' needs to be carefully managed as 
> the language takes shape.
>
>

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

[elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

['Rupert Smith' via Elm Discuss]

On Thursday, March 23, 2017 at 8:15:51 PM UTC, Simon wrote:
>
> It's pretty clear that these practices are frowned upon, but the shift to 
> 'kernel' sounds like a plan to squeeze the pragmatic programmer's options 
> further. I hope that's not the case.
>

I think all that is happening is that Native is being renamed to Kernel to 
reduce confusion. At the moment when we say 'Elm' and 'native' in the same 
sentence we could mean an Elm Native module used to implement its kernel, 
or native javascript code through ports.

I can't be certain of the details but I think your function would just be 
re-written as:

var _user$project$Kernel_Msgpack = function() { ... }

But you won't be able to publish it officially and will have to use 
elm-github-install.

It makes sense to me anyway, the 'kernel' needs to be carefully managed as 
the language takes shape.

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

Re: [elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

[Noah Hall]

> The work around is a native file along the lines of (or see this NoRedInk 
> library):

Sidenote: That is not a NoRedInk library. I do not work at NoRedInk
any more. It's a eeue56 library. It's important to distinct the two.

On Fri, Mar 24, 2017 at 4:19 AM, Martin Bailey  wrote:
> I suggested in elm-dev that adding a BitStream interface in Elm would make
> this kind of JS interop unnecessary. As it stands, one can't implement
> MsgPack in Elm since the only link to the outside world is JSON/String and
> binary data isn't valid UTF-16. I'd like to implement LZ-String in Elm for
> local storage compression but am not sure whether that'll be possible at
> some point. In the meantime, you can still write native/kernel code but just
> can't share it with the ecosystem.
>
> --
> 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.

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

[elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

[Martin Bailey]

I suggested in elm-dev that adding a BitStream interface in Elm would make 
this kind of JS interop unnecessary. As it stands, one can't implement 
MsgPack in Elm since the only link to the outside world is JSON/String and 
binary data isn't valid UTF-16. I'd like to implement LZ-String in Elm for 
local storage compression but am not sure whether that'll be possible at 
some point. In the meantime, you can still write native/kernel code but 
just can't share it with the ecosystem.

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

[elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

[Robin Heggelund Hansen]

The barriers are already built, the recent discussion mostly revolves on 
how we talk about the current barriers to make things more clear for 
beginners. Nothing is going to prevent you from using native/kernel code in 
your own project. You just won't be able to share it on elm-packages (which 
is still the case today).

torsdag 23. mars 2017 21.15.51 UTC+1 skrev Simon følgende:
>
> On elm-dev I get the impression that bigger barriers are being built to 
> towards javascript interop.
>
> I think building the barriers before the webapi is provided in Elm is the 
> wrong way around, but that's not the only case where practical needs are at 
> risk.
>
> Consider msgpack - a sort of compressed json. It's well specified but 
> today not much used. No one has written a library for it in Elm, but there 
> is a well-tested JS one. The encoding is simply calculations, so in the 
> normal run of things this should be a synchronous operation. If ports 
> returned Tasks this would not be a huge issue, but they return Commands and 
> thus force you back around the update loop (and the creation of an extra 
> Msg, which makes code intent less transparent).
>
> The work around is a native file along the lines of (or see this NoRedInk 
> library 
> ):
>
> ```
> var _user$project$Native_Msgpack = function() {
>
> function encode(k) {
> return msgpack.encode(k.kwd);
> }
> }
> ```
>
> It's pretty clear that these practices are frowned upon, but the shift to 
> 'kernel' sounds like a plan to squeeze the pragmatic programmer's options 
> further. I hope that's not the case.
>
>

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