On Wednesday, 28 December 2016 21:23:19 UTC+7, Peter Damoc wrote: > > > > On Wed, Dec 28, 2016 at 3:10 PM, GordonBGood <gordo...@gmail.com > <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 some Sub's with event managers and some without would somehow mix up the system. 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 as they only are fired for the specific Subs for which they are defined but work behind=the=scenes, then their application doesn't need to be concerned their implimentation. That leaves me impressed with the ease-of-use for Elm, with my biggest wish list items are all concerned with making Elm faster as is the subject of the thread; but it is still early days for optimization of 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 compiler magic to not use functions at all when not necessary (as has been already done for Records, and commonly used Tuples, which is why these are not created with library functions). I note that the current 0l18 compiler already does quite a lot in inlining of native functions/operators (except for comparison, which is the optenint post's concern) A more minor issue is the way immutability has been implemented in the existing libraries, especially the Array library: So much attention has been paid to making the `set` function have a better big O performance that it has built up a considerably large constant overhead in all Array operations so that these are too slow to use for anything serious. A better approach is the Haskell one for immutable arrays where they would be standard JSArrays (in this context) treated immutably without an equivalent to the`set` function at all and where all transmuting of arrays is handled by transmuting functions working on the whole array. In Haskell the transmuting functions are based on (relatively efficient) lazy lists which thus avoid excessive memory use, but I am suggesting that in Elm they would be based on passed-in functions where the new temporarily mutable array is an argument whose type cannot be created in Elm code but can only exist when passed into the context of these transmuting functions as an argument; then, in order to get speed, one would not work by setting array elements individually, but would try to minimize the creation of many new immutable arrays by the function that was passed into the creation function in the first place. However, as library concerns, this can easily;be fixed later, and if necessary in the interim, it wouldn't be too hard to create the required libraries. The only reason that I suggest these things is that I agree with Evan that JavaScript would ideally only be used as necessary in libraries, with the majority of applications never having to deal with it; however, with the current version there seems to be various applications where Elm code is not performant enough. -- 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.
