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.
