Just to make it clear, I'm not particularly calling for an easier way to create "subscriptions". I'm calling for a way to do one of the following — either is fine, each have their pluses and minuses:
1. Expose a synchronous, externally defined function that takes JSON (or really anything a command port supports) in and returns JSON (or really anything a subscription port supports) out. - or - 2. Expose a factory for externally defined asynchronous tasks where the task when executed receives JSON (etc) in and resolves to JSON (etc) when finished. The former is easier to integrate into general computation. The latter more clearly reflects that the computation occurs "elsewhere" and must be managed as such. Ports as they exist in 0.18 do not appear to offer this. If you want to make a request and receive a response, you need to make the request through a command port and receive the response through a subscription port. If you want to make multiple requests and receive multiple responses, you must do something to match responses with the code waiting for them which generally means generating and managing some form of ID's. The code to do that starts to look a lot like an effects manager, but the documentation discourages writing those. One could probably make this work via an out message based design with a pseudo-effects manager at the top level to manage ID's and talk to the ports but note that this pseudo-effects manager will be part of the model and will be storing functions — something that there is also advice to avoid doing. Or if ports are a sufficient answer and I'm just not seeing it, then maybe we need more and better examples for, in the case of this thread, how you move an expensive computation out of Elm and over to JavaScript. Mark > On Dec 27, 2016, at 11:41 PM, GordonBGood <[email protected]> wrote: > > > >> On Wednesday, 28 December 2016 14:18:13 UTC+7, Mark Hamburg wrote: >> My point was that the calls for Elm optimization could largely be mitigated >> through a combination of fast enough for most purposes (arguably already >> there) coupled with a reasonable escape hatch to the host environment (as of >> now JavaScript and not really there) for the cases when it isn't. I'm >> suggesting that rather than investing in fancy compiler changes, some >> changes in the runtime architecture to allow performance intensive central >> loops to be written in other ways would be cheaper, simpler, and would >> arguably address some of the other issues that have floated up recently. >> >> Elm has a weird ambivalence about native code. On the one hand, Evan has >> pushed back pretty hard in the past out of fear of getting tied to crappy >> JavaScript libraries and has pushed for doing everything in Elm. This is >> reflected in the relatively small amount of native code based work in the >> standard Elm package repository. On the other hand, when pushed on how one >> is supposed to do something that is currently difficult in Elm — e.g., some >> MDL conventions — others in the community have pushed for using native code >> rather than trying to write it in Elm. >> >> My recommendation would be a middle path that says we believe most things >> are better in Elm but here are its limitations and here is how you can >> cleanly and easily reach outside of Elm when those limitations prove to be a >> problem. While the currently documented mechanisms may be clean, they aren't >> easy for many cases. Ports are extremely awkward for cases that require both >> a request and a response to that request. Effects managers are undocumented >> and discouraged. And native modules themselves are barely even admitted to >> let alone documented as a thing. Improve that situation and any concerns >> over both performance and interfacing to the broader world are substantially >> mitigated and Elm can better focus on its core mission. Fail to improve that >> situation and every effort to grow the market for Elm will also grow the >> pressure for it to do everything well. > > Mark, you raise a good point: as an interim measure, make it easier to > generally interface to JavaScript including easily adding subscriptions if > necessary. But that will only happen if Evan and others see it that way, > which they may not if they see it as "Elm is already good enough (for our > use)". > -- > 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. -- 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.
