I know this was from last month -- I'm going back and reading through the list -- but I have separately arrived at a similar conclusion. I split the update function, separating effects from events. The difference being that my implementation separates their messages as well. Otherwise, there is no explicit "accept" phase (from the propose / accept / learn pattern above). Normally in Elm, all messages are always accepted as potentially updating the model. They also performing some logic (calculating new values, setting up effects).
In my implementation, the `view` does "propose" (through the user's actions) because it returns a Cmd Act. The `perform` method (the half of `update` that returns a Cmd) does "accept" as it calculates and decides what Facts (if any) and/or effects result from the proposal. The `apply` method (the half of `update` that does model changes) does "learn" because it takes Facts and applies them to the model. The downside with this implementation is that generated Facts must go through the Cmd (implying possible delay even without I/O) in order to get passed back through the architecture. A recursive update is doable, but violates the idea of separating the accept and learn phases. https://gist.github.com/kspeakman/109475ecdd3068a022b59f7f73c9485a#gistcomment-1848988 I seem to be somewhat spamming this link lately, so last time I post it unless somebody asks about it. I was hoping to get more feedback, but I'm just going to start making an app using this and see what happens. On Friday, June 17, 2016 at 10:30:46 AM UTC-5, Peter Damoc wrote: > > 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] <javascript:> > > 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] <javascript:>. >> 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.
