On Wednesday, December 14, 2016 at 12:18:01 PM UTC-6, Joey Eremondi wrote: > > Sure, I could abuse it to call a stateful js ap > > > Which you can currently do with Cmd ports! We'd just want to wrap it in > some type like Task or Cmd, and then it would be nicely segregated from > pure code. >
Correct. I phrased that badly, I meant "*Sure, I could call supposedly pure js code to compute a value, but that js happens to have some unintended side effect or stateful behavior, causing problem if the Elm compiler ...*". Task or Cmd would still be the right way to do all *intentional* side effects or communication. But calling some js loaded in the browser right alongside my Elm code to synchronously compute *layout(graph) *should be handled as similarly as possible to doing all the computation in Elm itself. > > On Wed, Dec 14, 2016 at 10:00 AM, Desmond D'Souza <[email protected] > <javascript:>> wrote: > >> I would love to be able to make synchronous functional calls to js and >> get a Result back. >> >> Taking simple clean synchronous functional code (e.g. if it were all in >> Elm), and being forced to chop out bits into async calls with async Msg >> callbacks (just because it is not all in Elm) impacts my code in unpleasant >> ways: >> >> 1. weird async bugs: will my originally sync call to *layout(graph)* get >> the layout answer back *after *the user has switched to another graph? >> 2. pollution of model and update: >> - I need to stuff into my model bits that were simple transient >> local variables before, and maintain those extra bits everywhere in my >> code. Forget to clear them somewhere, and chunks of my code like >> another >> update branch or a view function, think I have a current graph waiting >> for >> a layout. >> - I add more checks into my update to deal with possibly getting >> intervening unrelated async inputs >> 3. API bloat: why does *AndHereIsYourLayoutBack* need to be part >> of my API, when that is already explicit through the outgoing call >> mechanism (e.g. via something like a synchronous port, or some >> alternative) >> >> I think #1 would be somewhat alleviated by synchronous tasks from this >> thread >> <https://groups.google.com/forum/?fromgroups#!topic/elm-discuss/ejv98qDe7Oo>, >> >> but #2 and #3 remain. >> >> Properly supporting this use case would be good for Elm. Sure, I could >> abuse it to call a stateful js api, causing problems if the Elm compiler >> moves expression evaluation order around, hence I use some *unsafe* marker >> either as an annotation to myself or to the compiler. >> >> >> On Wednesday, December 14, 2016 at 4:48:06 AM UTC-6, Rupert Smith wrote: >>> >>> >>> >>> On Tuesday, December 13, 2016 at 3:42:23 PM UTC, Joey Eremondi wrote: >>>> >>>> the elm package repo would very quickly get poluted with js code that >>>>> causes runtime exceptions >>>> >>>> >>>> But, Tasks have error handling built into them. We could do something >>>> similar with synchronous code, just catch any exceptions thrown, and treat >>>> the value in Elm as something like a Result. >>>> >>> >>> > the elm package repo would very quickly get poluted with js code that >>> causes runtime exceptions _* and is not portable *_ >>> >>> Result would work, but the not portable bit is equally impoertant. >>> >>> >> -- >> 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 [email protected] <javascript:>. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
