Re: [elm-discuss] Stance on native APIs for 0.18?

['Rupert Smith' via Elm Discuss]

On Friday, December 16, 2016 at 7:32:11 PM UTC, Desmond D'Souza wrote:
>
> I don't see how refactoring my Model, Msg, update in order to use an async 
> Task / Cmd + Msg callback is a better choice, specially since I would want 
> to know if things went wrong on the js side anyway.
>

I came accross this talk post yesterday and thought it was worth sharing 
here as it seems relevant to the discussion:

http://www.codemesh.io/codemesh2015/evan-czaplicki

In short, message passing concurrency as inspired by Concurrent Programming 
in ML was chosen as the preferred framing of concurrency to reduce 
accidental complexity. I've only looked through the slide deck not watched 
the video yet, but it looks interesting.

One for the christmas reading list perhaps:

http://www.cambridge.org/gb/academic/subjects/computer-science/distributed-networked-and-mobile-computing/concurrent-programming-ml?format=PB=9780521714723

-- 
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] Stance on native APIs for 0.18?

[Desmond D'Souza]

Sorry to be dense, but ... in what actual scenario would the following 
cause problems, assuming I am writing for the browser?

   - Allow Elm code to make synchronous function calls to js, expecting a 
   js value wrapped in a Result
  - Use encoders / decoders if needed at the boundary, a decode failure 
  yielding a Result.Err
   - The Elm-side type signatures of the outgoing call and the Result 
   expected back are the complete contract
   - On the elm-to-js-bridge wrap a try-catch around the call to yield 
   either Result.Ok or Result.Err
   - If the concern is the Elm compiler's right to shuffle evaluation order 
   in ways the side-effect prone js might not like, use the "unsafe" or 
   "native" annotation to guide the user (and optionally or longer term, the 
   compiler).

I don't see how refactoring my Model, Msg, update in order to use an async 
Task / Cmd + Msg callback is a better choice, specially since I would want 
to know if things went wrong on the js side anyway.


On Friday, December 16, 2016 at 10:32:33 AM UTC-6, Mark Hamburg wrote:
>
> My view of the ideal world here with respect to JavaScript is that 
> JavaScript (or any other foreign language host) is basically a separate 
> universe that gets orchestrated by and communicates with Elm. Since Elm is 
> implemented as compiling to JavaScript and it runs within the JavaScript 
> universe, we can't actually protect it from ill-behavior in that universe 
> but that's an artifact of implementation. If one pretends that the Elm and 
> JavaScript universes are separate — because some day they might be — then 
> one needs to recognize that it is very difficult to arrange for synchronous 
> behavior in another universe. Many systems allow one to do it, but it tends 
> to block in ugly ways and if at all possible you want to avoid it. So, I 
> think it's pretty natural to view Elm's interaction with an external 
> universe as consisting of tasks to perform (asynchronously) and potentially 
> subscriptions by which to watch that universe — again asynchronously.
>
> One of the challenges in multi-universe systems is object lifetimes. 
> Cross-universe GC is hard as a general problem. If, however, we say that 
> the JavaScript universe is subordinate to the Elm universe in that Elm can 
> hold references to JavaScript objects but not the other way around, then 
> this problem goes away.
>
> One area where I will admit this notion is less clear is how animation or 
> anything requiring tight — i.e., synchronous — coupling should work. In 
> this case, the JavaScript universe essentially wants to fire off a message 
> to Elm and then block waiting for a return value. That's a pain for the 
> JavaScript side but it's what is essentially happening now anyway. If 
> animation synchronization didn't matter, then one could imagine a version 
> in which the JavaScript universe would fire off strobes at animation frames 
> to which the Elm universe could respond by calling view and pushing a new 
> HTML tree back to JavaScript. The JavaScript universe would not, however, 
> block in the meantime. The net result might be pretty similar to where 
> things are now but it feels like there could be slightly greater 
> opportunity for skew.
>
> Mark
>
> On Fri, Dec 16, 2016 at 4:39 AM, Vojtěch Král  > wrote:
>
>>
>> Dne čtvrtek 15. prosince 2016 19:44:20 UTC+1 Roland Kuhn napsal(a):
>>>
>>>
>>> Again wrong: just having a certain type does not enable client code to 
>>> handle the fallout—because the effects of JS code are literally arbitrary. 
>>> The only achieved effect is that the fallout is signaled in the type 
>>> system. But then if most of the code is reasonable despite being JS, most 
>>> people will just run these Tasks as if they’re fine anyway, and the 
>>> function of the type marker is lost—it just makes life a little more 
>>> miserable where people are forced to jump through hoops.
>>>
>>  
>> That's not entirely true. I agree that generaly the problem of JS code 
>> having arbitrary side-effects cannot be solved statically/automatically, 
>> but these type system facilities (Task, Result) do help, methinks. They can 
>> be useful for handling errors that are expected as well as, for example, 
>> catching JS exceptions thrown down the stack. I definitely wouldn't mark 
>> them useless.
>>
>> Anyhow, did anyone manage to get Evan's opinion on this thread?
>>
>> -- 
>> 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 

Re: [elm-discuss] Stance on native APIs for 0.18?

[Mark Hamburg]

My view of the ideal world here with respect to JavaScript is that
JavaScript (or any other foreign language host) is basically a separate
universe that gets orchestrated by and communicates with Elm. Since Elm is
implemented as compiling to JavaScript and it runs within the JavaScript
universe, we can't actually protect it from ill-behavior in that universe
but that's an artifact of implementation. If one pretends that the Elm and
JavaScript universes are separate — because some day they might be — then
one needs to recognize that it is very difficult to arrange for synchronous
behavior in another universe. Many systems allow one to do it, but it tends
to block in ugly ways and if at all possible you want to avoid it. So, I
think it's pretty natural to view Elm's interaction with an external
universe as consisting of tasks to perform (asynchronously) and potentially
subscriptions by which to watch that universe — again asynchronously.

One of the challenges in multi-universe systems is object lifetimes.
Cross-universe GC is hard as a general problem. If, however, we say that
the JavaScript universe is subordinate to the Elm universe in that Elm can
hold references to JavaScript objects but not the other way around, then
this problem goes away.

One area where I will admit this notion is less clear is how animation or
anything requiring tight — i.e., synchronous — coupling should work. In
this case, the JavaScript universe essentially wants to fire off a message
to Elm and then block waiting for a return value. That's a pain for the
JavaScript side but it's what is essentially happening now anyway. If
animation synchronization didn't matter, then one could imagine a version
in which the JavaScript universe would fire off strobes at animation frames
to which the Elm universe could respond by calling view and pushing a new
HTML tree back to JavaScript. The JavaScript universe would not, however,
block in the meantime. The net result might be pretty similar to where
things are now but it feels like there could be slightly greater
opportunity for skew.

Mark

On Fri, Dec 16, 2016 at 4:39 AM, Vojtěch Král 
wrote:

>
> Dne čtvrtek 15. prosince 2016 19:44:20 UTC+1 Roland Kuhn napsal(a):
>>
>>
>> Again wrong: just having a certain type does not enable client code to
>> handle the fallout—because the effects of JS code are literally arbitrary.
>> The only achieved effect is that the fallout is signaled in the type
>> system. But then if most of the code is reasonable despite being JS, most
>> people will just run these Tasks as if they’re fine anyway, and the
>> function of the type marker is lost—it just makes life a little more
>> miserable where people are forced to jump through hoops.
>>
>
> That's not entirely true. I agree that generaly the problem of JS code
> having arbitrary side-effects cannot be solved statically/automatically,
> but these type system facilities (Task, Result) do help, methinks. They can
> be useful for handling errors that are expected as well as, for example,
> catching JS exceptions thrown down the stack. I definitely wouldn't mark
> them useless.
>
> Anyhow, did anyone manage to get Evan's opinion on this thread?
>
> --
> 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.

Re: [elm-discuss] Stance on native APIs for 0.18?

[Vojtěch Král]

Dne čtvrtek 15. prosince 2016 19:44:20 UTC+1 Roland Kuhn napsal(a):
>
>
> Again wrong: just having a certain type does not enable client code to 
> handle the fallout—because the effects of JS code are literally arbitrary. 
> The only achieved effect is that the fallout is signaled in the type 
> system. But then if most of the code is reasonable despite being JS, most 
> people will just run these Tasks as if they’re fine anyway, and the 
> function of the type marker is lost—it just makes life a little more 
> miserable where people are forced to jump through hoops.
>
 
That's not entirely true. I agree that generaly the problem of JS code 
having arbitrary side-effects cannot be solved statically/automatically, 
but these type system facilities (Task, Result) do help, methinks. They can 
be useful for handling errors that are expected as well as, for example, 
catching JS exceptions thrown down the stack. I definitely wouldn't mark 
them useless.

Anyhow, did anyone manage to get Evan's opinion on this thread?

-- 
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] Stance on native APIs for 0.18?

[Roland Kuhn]

> 15 dec. 2016 kl. 19:27 skrev Joey Eremondi :
> 
> sticking it into a monad does not make it any more reasonable
> 
> The thing is, it's not about calling unreasonable code, it's about calling 
> *potentially* unreasonable code.

Which is the same thing: being potentially unreasonable means that we cannot 
reason about it.

> Putting it in a Monad doesn't make it more reasonable, but it means that the 
> reasonability of pure Elm code is not compromised, and unreasonable JS can't 
> make Elm behave in an unreasonable way.

Wrong: the Elm code that chains off those Tasks is held hostage by the 
unreasonability of the called code. If calling JS is “just a Task” then 
suddenly Tasks don’t compose anymore in the sense that pure functions would. 
You cannot compose multiple impure actions in a pure way with the expectation 
that that makes the impure actions composable.

> And making it return a Result (or similar, like Task's error type) ensures 
> that the uses of this code *must* handle any unreasonably that occurs.

Again wrong: just having a certain type does not enable client code to handle 
the fallout—because the effects of JS code are literally arbitrary. The only 
achieved effect is that the fallout is signaled in the type system. But then if 
most of the code is reasonable despite being JS, most people will just run 
these Tasks as if they’re fine anyway, and the function of the type marker is 
lost—it just makes life a little more miserable where people are forced to jump 
through hoops.

To make it clear, I am not proposing a certain strategy, I am not involved in 
the Elm community enough for that, but I’d like to counter certain arguments 
that I have seen go wrong. Placing effectful code in monads is not a solution 
because the underlying problem fundamentally cannot be solved. A solution would 
mean to devise an algebra for the domain of effects that is to be modeled and 
to thoroughly understand it (including its limitations). Calling arbitrary code 
cannot be treated like that since it is arbitrary.

Regards,

Roland

> 
> Likewise, with parallelism, the encapsulation does help. The monadic andThen 
> function is the perfect tool for chaining operations together into blocks 
> which must be run atomically, and while you can get race conditions, the 
> monadic structure ensures that those ill effects never leak into pure code. 
> 
> On Thu, Dec 15, 2016 at 9:56 AM, Roland Kuhn  > wrote:
> Hi Mark (and others),
> 
>> 15 dec. 2016 kl. 18:40 skrev Mark Hamburg > >:
>> 
>> Having external compute run asynchronously opens the possibility of having 
>> it run in parallel some day.
> 
> As much as I sympathise with the notion of encapsulating “dirty” code and 
> marking it out, making it asynchronous is the wrong direction: these calls 
> are performing uncontrolled side-effects, hence running them in parallel is 
> the worst choice possible.
> 
> Another observation is that taking unreasonable code (i.e. code that cannot 
> easily be reasoned about) and sticking it into a monad does not make it any 
> more reasonable. If calling unreasonable code is the goal, then there is no 
> improvement to be had over just calling it.
> 
> Regards,
> 
> Roland
> 
>> That said, if Elm were to emphasize that sort of programming, it might drive 
>> some shifts in how other pieces are structured. The world is going async — 
>> see node.js — but it's a painful process. Tasks might be enough but I don't 
>> know that anyone has written a complex process around tasks and any such 
>> process wouldn't leverage the Elm debugger. A bigger problem is that once 
>> you ask for something to be computed, it really helps if there is a way to 
>> say "nevermind". Reactive networks also help hide some of the management 
>> issues for this sort of work but Elm has been moving away from those.
>> 
>> So, I embrace async tasks but I think they also then need to be embraced by 
>> the language/runtime/app-architecture.
>> 
>> Mark
>> 
>> On Wed, Dec 14, 2016 at 9:03 PM, Desmond D'Souza > > wrote:
>> 
>> 
>> On Wednesday, December 14, 2016 at 1:30:48 PM UTC-6, Rupert Smith wrote:
>> On Wednesday, December 14, 2016 at 6:00:14 PM UTC, Desmond D'Souza wrote:
>> I would love to be able to make synchronous functional calls to js and get a 
>> Result back.
>> 
>> Would you want to publish this code to elm-package?
>> 
>> Yes. 
>>  
>> 
>> Would the javascript your package calls be included in the package? 
>> 
>> I don't know, but do have a naive answer. If I had written all of it in Elm, 
>> split into App.elm and GraphLayout.elm, I could publish both modules bundled 
>> into a single package or split into two, and Elm + elm-package spells out 
>> what a package user needs to know and do in both cases. If GraphLayout is in 
>> javascript, 

Re: [elm-discuss] Stance on native APIs for 0.18?

[Joey Eremondi]

>
> sticking it into a monad does not make it any more reasonable


The thing is, it's not about calling unreasonable code, it's about calling
*potentially* unreasonable code. Putting it in a Monad doesn't make it more
reasonable, but it means that the reasonability of pure Elm code is not
compromised, and unreasonable JS can't make Elm behave in an unreasonable
way. And making it return a Result (or similar, like Task's error type)
ensures that the uses of this code *must* handle any unreasonably that
occurs.

Likewise, with parallelism, the encapsulation does help. The monadic
andThen function is the perfect tool for chaining operations together into
blocks which must be run atomically, and while you can get race conditions,
the monadic structure ensures that those ill effects never leak into pure
code.

On Thu, Dec 15, 2016 at 9:56 AM, Roland Kuhn 
wrote:

> Hi Mark (and others),
>
> 15 dec. 2016 kl. 18:40 skrev Mark Hamburg :
>
> Having external compute run asynchronously opens the possibility of having
> it run in parallel some day.
>
>
> As much as I sympathise with the notion of encapsulating “dirty” code and
> marking it out, making it asynchronous is the wrong direction: these calls
> are performing uncontrolled side-effects, hence running them in parallel is
> the worst choice possible.
>
> Another observation is that taking unreasonable code (i.e. code that
> cannot easily be reasoned about) and sticking it into a monad does not make
> it any more reasonable. If calling unreasonable code is the goal, then
> there is no improvement to be had over just calling it.
>
> Regards,
>
> Roland
>
> That said, if Elm were to emphasize that sort of programming, it might
> drive some shifts in how other pieces are structured. The world is going
> async — see node.js — but it's a painful process. Tasks might be enough but
> I don't know that anyone has written a complex process around tasks and any
> such process wouldn't leverage the Elm debugger. A bigger problem is that
> once you ask for something to be computed, it really helps if there is a
> way to say "nevermind". Reactive networks also help hide some of the
> management issues for this sort of work but Elm has been moving away from
> those.
>
> So, I embrace async tasks but I think they also then need to be embraced
> by the language/runtime/app-architecture.
>
> Mark
>
> On Wed, Dec 14, 2016 at 9:03 PM, Desmond D'Souza 
> wrote:
>
>>
>>
>> On Wednesday, December 14, 2016 at 1:30:48 PM UTC-6, Rupert Smith wrote:
>>>
>>> On Wednesday, December 14, 2016 at 6:00:14 PM UTC, Desmond D'Souza wrote:

 I would love to be able to make synchronous functional calls to js and
 get a Result back.

>>>
>>> Would you want to publish this code to elm-package?
>>>
>>
>> Yes.
>>
>>
>>>
>>> Would the javascript your package calls be included in the package?
>>>
>>
>> I don't know, but do have a naive answer. If I had written all of it in
>> Elm, split into App.elm and GraphLayout.elm, I could publish both modules
>> bundled into a single package or split into two, and Elm + elm-package
>> spells out what a *package user* needs to know and do in both cases. If
>> GraphLayout is in javascript, the overall package story should stay as
>> close as reasonably possible *for the package user, *and Elm +
>> elm-package should spell out what that user needs to know and do.
>>
>> --
>> 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.
>
>
> --
> 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.

Re: [elm-discuss] Stance on native APIs for 0.18?

[Roland Kuhn]

Hi Mark (and others),

> 15 dec. 2016 kl. 18:40 skrev Mark Hamburg :
> 
> Having external compute run asynchronously opens the possibility of having it 
> run in parallel some day.

As much as I sympathise with the notion of encapsulating “dirty” code and 
marking it out, making it asynchronous is the wrong direction: these calls are 
performing uncontrolled side-effects, hence running them in parallel is the 
worst choice possible.

Another observation is that taking unreasonable code (i.e. code that cannot 
easily be reasoned about) and sticking it into a monad does not make it any 
more reasonable. If calling unreasonable code is the goal, then there is no 
improvement to be had over just calling it.

Regards,

Roland

> That said, if Elm were to emphasize that sort of programming, it might drive 
> some shifts in how other pieces are structured. The world is going async — 
> see node.js — but it's a painful process. Tasks might be enough but I don't 
> know that anyone has written a complex process around tasks and any such 
> process wouldn't leverage the Elm debugger. A bigger problem is that once you 
> ask for something to be computed, it really helps if there is a way to say 
> "nevermind". Reactive networks also help hide some of the management issues 
> for this sort of work but Elm has been moving away from those.
> 
> So, I embrace async tasks but I think they also then need to be embraced by 
> the language/runtime/app-architecture.
> 
> Mark
> 
> On Wed, Dec 14, 2016 at 9:03 PM, Desmond D'Souza  > wrote:
> 
> 
> On Wednesday, December 14, 2016 at 1:30:48 PM UTC-6, Rupert Smith wrote:
> On Wednesday, December 14, 2016 at 6:00:14 PM UTC, Desmond D'Souza wrote:
> I would love to be able to make synchronous functional calls to js and get a 
> Result back.
> 
> Would you want to publish this code to elm-package?
> 
> Yes. 
>  
> 
> Would the javascript your package calls be included in the package? 
> 
> I don't know, but do have a naive answer. If I had written all of it in Elm, 
> split into App.elm and GraphLayout.elm, I could publish both modules bundled 
> into a single package or split into two, and Elm + elm-package spells out 
> what a package user needs to know and do in both cases. If GraphLayout is in 
> javascript, the overall package story should stay as close as reasonably 
> possible for the package user, and Elm + elm-package should spell out what 
> that user needs to know and do.
> 
> -- 
> 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 
> .

-- 
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] Stance on native APIs for 0.18?

[Wil C]

I was reading the various message posts, and I happened upon this post on 
the stance of native modules from a year ago:

https://groups.google.com/forum/#!searchin/elm-dev/native$20author$3aeva...@gmail.com/elm-dev/1JW6wknkDIo/H9ZnS71BCAAJ

I was just wondering if there was an updated stance? Or this is pretty much 
the way going forward?

I'm all cool with the stance. But for some libraries, I hesitate to 
reimplement in elm, such as a parser/renderer for markdown or vega. It 
seems non-trivial. And I worry about having to track the upstream changes, 
since I'm neither a markdown for vega expert. I also noticed that the 
standard elm-markdown uses a minified JS version of marked.js in it as a 
native module. Even then, the renderer wasn't implemented in pure Elm. 

So right now, I'm using ports, as suggested, and a native module for 
commonmark.js. It makes some things a bit cumbersome, but it's working out 
so far. Just wanted to know if there were any thoughts from Elm maintainers 
about the topic going forward.

Wil

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