On Wednesday, 28 December 2016 21:23:19 UTC+7, Peter Damoc wrote: > > > > On Wed, Dec 28, 2016 at 3:10 PM, GordonBGood <[email protected] > <javascript:>> wrote: > >> >> So you are saying we can already do the following: >> >> type Msg = ProgProgress Progress | ProgCancelled | ProgDone Answer | Tick >> >> port startLRP : () -> Cmd msg >> >> port cancelLRP : () -> Cmd msg >> >> subscriptions model = >> Subs.batch >> [ lrpProgress ProgProgress >> , lrpCancelled ProgCancelled >> , lrpDone ProgDone >> , Timer.every 1000 Tick ] >> >> port lrpProgress : (Progress -> Msg) -> Sub Msg >> >> port lrpCancelled : (() -> Msg) -> Sub Msg >> >> port lrpDone : (Answer -> Msg) -> Sub Msg >> >> with the Native JavaScript as per the link for each of the ports, Types >> all defined, update function handling all Msg cases, and the subscription >> system will automatically handle getting each subscription to the right Msg? >> >> Will this not cause problems with the Timer.every subscription? >> >> > This looks like valid code to me. > I would implement it differently, in a way where the model captures the > current state of the process and the subscription uses that state to listen > only to the relevant Subs but... that's more of an optimization. >
I would implement it differently too, but this was just for a quick example. > Also, I assume that Answer and Progress are aliases to types that can > travel the ports. > Of course, didn't want to pin them to specify types whether they be Int, Float, Record, Union, Tagged Union, Array, or whatever, is immaterial. What kind of problems do you foresee with Timer.every? > That's why I added it as I was concerned that using Sub's with event managers and without would somehow mix up the saystem. I've now tested this (got sidetracked by looking for something good to write the fast bits that isn't JavaScript or even TypeScript as you can see in the latter part of the thread), and it works exactly as advertised, so no worries. I guess my take away on Event/effect (defined in `effect` modules) managers is that they are required when there is a possibility that the same Sub would be used for more than one Msg, possibly of different kinds; as long as one can write code, as here or even a little more complex as you are suggesting, then they are not required, and they only are fired for the specify Subs for which they are defined but work behind=the=scenes so that the actual use of them doesn't need to be concerned with them. That leaves me impressed with the ease-of-use for Elm, with my biggest wish list all concerned with making Elm faster; but it is still early days for the language as long as it is still evolving. As raised in the opening post, the main concern is nested function calls as is a common bottleneck with functional languages, which is usually addressed with inlining functions where possible and specializations and rules defining when this can be used, also using com;piler magic to not use functions at all when not necessary (as has been already done for Records, and commonly used Tuples). A more minor issue is the way immutability has been implemented in the libraries, especially the Array library: So much attention has been paid to making the `set` function have a better big O performance that has built up a constant overhead in all Array operations so that these are too slow to use fpr anything serious. A better approach is the Haskell one for immutable arrays where they would be standard JSArrays (in this context) without an equivalent to the et -- 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.
