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 <vojtechkral.cub...@gmail.com> 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.
