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.
