Example apps with it, like a little game or a chat thing or something might be a great example so we can really see usage. :-)
On Tuesday, August 16, 2016 at 4:08:20 PM UTC-6, Kasey Speakman wrote: > > 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]> 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.
