function state(model) {return {isCounting: ..., blah: model.blah}
view=nap(state(present(action(model)))
represent
model.data
?
isDrawing
state(model) { return {isDrawing: true}}
state(model) { return {isDrawing: true, canvasId: 1}}
state(model) {
canvasIdsDrawing = model.data.canvases.any(started=true)
return {isDrawing: canvasIdsDrawing.length, canvasIds: canvasIdsDrawing}
}
state.representation
does not return a value. it makes me wonder if they are hung up on that detail. technically speaking, it actualy does always return a value -- undefined
. :^) at any rate, i wonder what your opinion is of that return value part, and its importance in the definition of a "pure function"
A function is a relation for which each value from the set the first components of the ordered pairs is associated with exactly one value from the set of second components of the ordered pair.
there is nothing in the definition of a function that specifies how it is used. The "function" is the "relation".
The function always evaluates the same result value given the same argument value(s).
is not logically equivalent to o = f(i)That is why there is not such thing as a "pure function" in math. Just function.
uh? that's kind of the opposite, I'd say 100% of the functions in Maths are pure, it happens that in programming we can write "things" that look syntactically like functions (o = f(i)) but they are not functions in the mathematical sense.
"uh? that's kind of the opposite, I'd say 100% of the functions in Maths are pure, it happens that in programming we can write "things" that look syntactically like functions (o = f(i)) but they are not functions in the mathematical sense."
That is exactly what I'm saying
I am trying to say that actions in SAM are functions which are pure with respect to the model
So here are the emails I sent:
9/2015 Chris Chedau
Bonjour Chris,
I really enjoyed your presentation at QCon / InfoQ. I am a (really) big fan of React.js. Ton travail sur React Native est vraiment tres important.
My background is SOA / Composite Applications / API Platforms and I feel that the React programming model is still a bit weak when it comes to connecting APIs to the model.
I came up with two patterns which might be interesting to the React team (Native or otherwise).
The first one I called it ReaCall (phonetically recall). ReaCall makes it easy to create Client APIs SDK that are decoupled from the Web Apps that consume the APIs.
The second pattern, SAM, is replacement for Flux. The formalism underlying to Flux is broken, I explain why here. SAM stands for "State-Action-Model" and IMHO is the correct formalism (Flux is based on Action-Model formalism).
I have created a really thin framework (component model) to use SAM easily: http://bitbucket.org/jdubray/star-javascript/src, here is an example implementing a "reliable API call with SAM".
Cheers,
Jean-Jacques ("JJ") Dubray
Then I wrote to Dan in December 2015
Dan,
Someone introduced me to Redux today, so pardon my ignorance. I came to similar conclusions when I started to use React and landed on Flux. I created earlier this year a very thin library (STAR) using TLA+ semantics which you might appreciate (TLA = temporal logic of action).
I modified slightly the semantics of TLA+ to make state machines explicit. While doing that, I realized that State Machines (Petri Nets) were based on an approximation that needs to fixed. Petri nets and traditional state-action models (such as the one you use in Redux) connect actions and states, I.e. the action decides what the target state is. This is an approximation, it does not have to be that way, the purpose of an action is to calculate new values (purely function), these values are then presented to a “type” (~store) that decides to accept these values (based on constraints and computes the resulting state). This is semantics I implemented in my framework (STAR – State, Type, Action, Relationship).
From what I understand in Redux, you are actually using that approximation (an action decides which states you end up in):
switch (action.type) {
case INVALIDATE_REDDIT:
return Object.assign({}, state, {
didInvalidate: true
})
Here is the library: https://bitbucket.org/jdubray/star-javascript/src (100% often source, free to use for any purpose)
Here is an explanation of the SAM pattern (State-Action-Model) http://www.ebpml.org/blog15/2015/06/sam-the-state-action-model-pattern/
Here is an example using SAM (a reliable API call): http://www.ebpml.org/blog15/2015/06/designing-a-reliable-api-call-component-with-sam/
I'd be truly honored if you take a look at STAR. STAR aligns the 3 core formalisms of programming: OO, FP and Petri Nets.
Cheers,
Dan responded in Feb:
Hi Jean-Jacques,
I’m sorry I did not respond to your request.
The only letter I see from you in my mailbox is an invitation to Gitter chat but I didn’t really understand the context around that invitation so I didn’t open it.
If you wrote a personal letter to me, I’m not sure where it ended up. :-/I have seen your article come up a couple of times in the discussions.
It’s great to see more people discuss and iterate on different architectures!I am definitely not intentionally ignoring your article.
I have moved into a new apartment in another country on a new job with a new team, and I’m struggling to find time to read everything I want.I will send you my thoughts when I find some time to dive into it.
I don’t want to rush this because it’s hard for me to learn new concepts, and I need to allocate time to do it.Thank you for your contributions to the community.
Cheers,
Dan
Here are the emails to Erik Meijer (May 2016)
Erik,
thank you for accepting my invitation to connect. I watch several of your videos/keynotes on reactive programming and it seems that there is a trend in the industry (Cycle.js / ELM and now Redux) to concentrate strictly separate "the effects from the logic". ELM speaks of "effects as data" and it looks like Redux is trying to do the same thing.
Not sure if you heard about the SAM pattern (I am the author and I'd be honored if you did, http://sam.js.org). I have created SAM as an interpretation, my interpretation of TLA+. I had a brief but intense exchange of emails with Dr. Lamport last year on creating a programming model aligned with the semantics of TLA+ and ultimately it resolved into SAM. In SAM there are three key elements: Actions which propose value to the model, the Model which Accept value (as a critical section), and the State function which is in charge of making sure that everyone who needs to learn about the changes in the application state, while triggering the next-action if there is any.
SAM does not care about effects because the model controls the critical section where the application state changes. No action can present data until a stable "State" is reached. Actions themselves can invoke APIs for instance before they present data to the model, SAM does not care since no application state has changed until the action present the data to the model. This means that actions can easily be changed and in particular, SAM inherits the notion of "program step" from TLA+.
So the question I have is what is your position on Cycle.js / ELM and the idea of separating effects from the business logic? From what I can tell, they are having a lot of difficulties doing so, Redux introduces ... Sagas (really?) and Cycle has changed again its core API.
From the videos that I have watched you seem to claim that it's not wise to try to separate effects from the logic, nor even desirable. Is that correct?
Apologies that's a pretty basic question, but it seems at this point that a lot of people are struggling with it.
thank you,
JJ-
Erik,
I apologize to bother you but this question keeps coming up. This is not a heated debate, at the moment, people are just trying to find the best way to deal with effects in Front-End architectures.
Not sure if I could interest you in joining our discussion room: https://gitter.im/jdubray/sam
Elm seems to be the most mature (from a Front-End perspective) in handling "effects as data", but even Richard Feldman (the authority in that question https://www.youtube.com/watch?v=6EdXaWfoslc) seems to not make a very good case for doing so. He claims in the talk, that Elm makes it possible to not have to write stubs to test your effects, but his code looks a lot like he is writing the stub(s) in the application code, so the gain seems to be pretty low.
Another argument that came about this week is that this "effect as data" approach seems to require that maintain additional state/status in your model just to keep track of what's in flight.
Anyways, I am sure your are busy, but I can assure you that this is one of most important questions at the moment in Front-End architecture.
Thank you,
JJ-