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 <jdub...@gmail.com> 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 <jam...@gmail.com> 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 <pda...@gmail.com> 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 < >>>>>> stefan.h...@gmail.com> 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 elm-discuss...@googlegroups.com. >>>>>>> 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 elm-discuss...@googlegroups.com. >>>>>> 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 elm-discuss...@googlegroups.com. >>> 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 elm-discuss+unsubscr...@googlegroups.com. > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
