Hi Mark (and others), > 15 dec. 2016 kl. 18:40 skrev Mark Hamburg <mhamburg...@gmail.com>: > > 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 <desm...@dsouzaville.com > <mailto:desm...@dsouzaville.com>> 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 > <mailto:elm-discuss+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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 > <mailto:elm-discuss+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
