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] > <javascript:>> 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] <javascript:>. >> 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.
