interesting article

[Stefan Houtzager]

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

[Peter Damoc]

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 

--
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/

[surfncode]

This is not the first time I read about SAM. The decoupling between model and actions seems a bit artificial. Just putting them into different functions doesn't mean the coupling magically disappear in my opinion. There still must be an implicit contract between those two, so that the model is able to interpret the action data format isn't it ? This just seem to create an hidden dependency inside the model update function instead of in plain sight as we have in elm now. Not sure it would really improve anything.

[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?

[Stefan Houtzager]

> 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:

[James Wilson]

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). 

[Nick H]

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 :-)

[James Wilson]

Other bits I learned from chatting to Jean were

- SAM decouples the code that decides what effects to produce from the message. This would basically mean splitting the update function into two parts; update the model first, and then inspect the new model only to decide which effect to run.
- SAM also allows you to completely ignore model updates if you like. Building on the above this would mean the function that updates the model retuning a book denoting whether it changed anything, so that the function responsible for running effect based on the model can be told not to bother.

I think it's all possible in Elm basically, and when I was working on code snippets I found times when I really wanted effects based on messages as well and it seemed to simplify things, and I struggled to see the concrete benefits of forcing a decoupling from the POV of implementing SAM in Elm.

[Jean-Jacques Dubray]

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.

[Peter Damoc]

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. 

[Riccardo]

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

[Peter Damoc]

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) . :) 

[Kasey Speakman]

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.

[OvermindDL1]

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.  :-)