You are right, the previous implementation was bugged. I have updated the gist to make it run the timer only on countdown
https://gist.github.com/pdamoc/c96714479d9f531fbc7468d5670ef576 I also moved the check from 0 to 1 for the launch as it was staying one extra second (a classical off-by-one error) . :) On Fri, Jun 17, 2016 at 5:46 PM, Riccardo <[email protected]> wrote: > Hey Peter, > I was looking at your code example, and I really like how it includes the > semantics of SAM (from my current understanding of them), and feels more > lightweight than other JS examples I have seen (imo a result of language > and architecture). > > One thing I am unclear about is how to implement the > next-action-predicate. > I don't know if a subscription to Timer is enough. For example, you would > want the timer to start when receiving the StartCountdown action, otherwise > your first "second" might be a bit short. Also, you wouldn't want the timer > to run unless you are in the Countdown "state" and interested in the > message it produces. > > What do you think? > > Thanks > Riccardo > > > On Monday, May 30, 2016 at 7:41:10 AM UTC+1, Peter Damoc wrote: >> >> Mr. Dubray, >> >> Welcome to the Elm list. :) >> >> From my past experience on this list I found that discussions without >> code tend to be less productive because, as I view it, the decisions >> regarding Elm's direction are being made on the grounds of both theory and >> practice. >> >> Evan has a repository of small examples that show how Elm code should be >> structured. >> https://github.com/evancz/elm-architecture-tutorial >> >> Maybe you could take a look at those examples and reimplement a proposed >> alternative way to structure the code, documenting the advantages you >> perceive. >> This way, advantages may become apparent enough to warrant a more >> thorough discussion. >> >> The Elm Architecture has the huge benefit of being extremely simple and >> quite solid. >> For it to be changed there have to be very clear benefits. >> >> I would like to add that, from the little that I've read, I found TLA+ to >> be extremely interesting. >> >> >> >> >> >> >> >> On Mon, May 30, 2016 at 4:51 AM, Jean-Jacques Dubray <[email protected]> >> wrote: >> >>> IMHO, modern front-end architecture do not pay enough attention to the >>> way application state is mutated. They focus either on "wiring" (RxJs) or >>> "effects". SAM's TLA+ semantics enforce three phases to mutating >>> application state: propose / accept / learn. These three phases define a >>> single "step". >>> >>> I find the TLA+ to be extremely healthy and certainly not incompatible >>> with Elm. I am just a bit concern with Elm effects or Redux Sagas that seem >>> to imply that some effects can be applied without implications on the >>> application state, and therefore applying the step flow: >>> propose/accept/learn. >>> >>> On Tuesday, May 24, 2016 at 1:54:19 PM UTC-7, Nick H wrote: >>>> >>>> Cool, thanks for that example. I can see the advantage of decoupling >>>> the actions from the effects. >>>> >>>> Even without being enforced by the core platform, I think an Elm >>>> programmer could follow this pattern without too much trouble. Much in the >>>> same way that the current platform architecture was originally built on top >>>> of the old Signal.foldp, I bet SAM could be implemented as a library. Would >>>> be an interesting experiment :-) >>>> >>>> On Tue, May 24, 2016 at 12:42 PM, James Wilson <[email protected]> >>>> wrote: >>>> >>>>> My impression from a brief discussion on the gitter chat room ( >>>>> https://gitter.im/jdubray/sam) about SAM with the creator is that >>>>> basically if you turn: >>>>> >>>>> update msg model = case msg of >>>>> Increment -> (model + 1, Cmd.none) >>>>> Decrement -> (model - 1, someEffect) >>>>> >>>>> into >>>>> >>>>> updateModel msg model = case msg of >>>>> Increment -> model + 1 >>>>> Decrement -> model - 1 >>>>> >>>>> makeActions model = >>>>> if model == 1 then someEffect else Cmd.none >>>>> >>>>> -- the same signature as my last example so it wires >>>>> -- into the elm architecture exactly as it would have before: >>>>> update model = >>>>> let newModel = updateModel model >>>>> in (newModel, makeActions newModel) >>>>> >>>>> Thereby decoupling the actions we want to perform from the >>>>> messages/events that led the model to be modified, you'd be on the right >>>>> track for doing SAM in Elm. >>>>> >>>>> To quote Jean-Jacques Dubray re the initial snippet: >>>>> >>>>> "When I look at the code you provided, I see a direct line of sight >>>>> between the events and the effects, and that's what SAM is trying to >>>>> break." >>>>> >>>>> I'm sure that there's more to it than just this, but other bits (eg >>>>> that actions do all the hard work of turning data into something ready for >>>>> your update function (or model.present in some of his examples) rather >>>>> than >>>>> the update function doing all of the hard work) basically seem to be the >>>>> case already in Elm. I do wonder about the distinction between the >>>>> component state in Elm (what we call the model) and the application wide >>>>> state (React would call this a Store) and how this relates/tallies up with >>>>> SAM (and more generally how best to structure this into an Elm app, though >>>>> I have some thoughts I'm playing with on this). >>>>> >>>>> >>>>> On Tuesday, 24 May 2016 19:47:56 UTC+1, Stefan Houtzager wrote: >>>>>> >>>>>> > What would need to change in the Elm architecture for it to match >>>>>> SAM? >>>>>> >>>>>> I'm just someone interested in learning elm, so I cannot answer. Are >>>>>> the architects of elm, following these messages, who can? Evan Czaplicki? >>>>>> And is this interesting enough to contact Jean-Jacques Dubray, Evan? >>>>>> >>>>>> >>>>>> Op dinsdag 24 mei 2016 20:30:55 UTC+2 schreef Nick H: >>>>>>> >>>>>>> Peter's description is very close to how I manage states in my code. >>>>>>> It never occurred to me that it might have its own name; it just seemed >>>>>>> the >>>>>>> most natural way to manage states within the Elm Architecture. >>>>>>> >>>>>>> The model is a union type. The action is a union type. The update >>>>>>> function is just a case statement, so actions that are nonsensical for >>>>>>> the >>>>>>> model state can be easily ignored. >>>>>>> >>>>>>> As far as I can tell, Dubray's criticism of the Elm Architecture is >>>>>>> summarized in this quote: >>>>>>> >>>>>>> "That assertion is erroneous. You would be missing a couple of >>>>>>> important parts: >>>>>>> - the logic that decides which state you are in so you can properly >>>>>>> compute the view and enable the actions associated to the state >>>>>>> - the next action predicate" >>>>>>> >>>>>>> The first point of complaint is that both the update and view >>>>>>> functions need a case statement. >>>>>>> The second point of complaint is that ... I am not sure. It seems to >>>>>>> me that Elm's Effects are filling the role of Dubray's next action >>>>>>> predicate just fine. >>>>>>> >>>>>>> These seem like aesthetic differences, so I am sure there is some >>>>>>> point that I am missing. What would need to change in the Elm >>>>>>> architecture >>>>>>> for it to match SAM? >>>>>>> >>>>>>> On Tue, May 24, 2016 at 1:22 AM, Peter Damoc <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Aligning Elm with TLA+ will make it even more solid from a >>>>>>>> theoretical point of view. >>>>>>>> >>>>>>>> SAM sounds very intriguing. I'm wondering if SAM couldn't be >>>>>>>> implemented in terms of TEA using a tagged union as Model. >>>>>>>> >>>>>>>> something like this: >>>>>>>> https://gist.github.com/pdamoc/c96714479d9f531fbc7468d5670ef576 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, May 24, 2016 at 8:51 AM, Stefan Houtzager < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> I am interested in learning elm. I just read an article from >>>>>>>>> Jean-Jacques Dubray. He thinks an alignment with "SAM" would make >>>>>>>>> elm stronger: >>>>>>>>> https://www.infoq.com/articles/no-more-mvc-frameworks#anch133142. >>>>>>>>> Discussions: https://gitter.im/jdubray/sam. >>>>>>>>> What do you think? Might it be interesting to start a discussion >>>>>>>>> with Jean-Jacques Dubray? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Kind regards, >>>>>>>>> >>>>>>>>> Stefan Houtzager >>>>>>>>> >>>>>>>>> Houtzager ICT consultancy & development >>>>>>>>> >>>>>>>>> www.linkedin.com/in/stefanhoutzager >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> There is NO FATE, we are the creators. >>>>>>>> blog: http://damoc.ro/ >>>>>>>> >>>>>>>> -- >>>>>>>> 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. >>>>> >>>> >>>> -- >>> 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. >>> >> >> >> >> -- >> There is NO FATE, we are the creators. >> blog: http://damoc.ro/ >> > -- > 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. > -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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.
