Sounds very interesting. I don't know anything about ML unfortunately. I thought maybe you would like an introduction to Beads, i can zip through the main design features via a screenshare if you are interested.
It is far simpler than React, and can generate Web, Desktop and Mobile apps, all from a single code base. I have a graph database inside the language, so i haven't used GraphQL. I did look at Neo4J when i was doing my project; not a big fan of Cypher, they didn't go far enough.
I have a finite state machine sub-language in Beads, it is very similar to your sam-js tool, but as it is built into the language it is probably more graceful to use. I haven't actually used it, because i haven't had a complicated enough state machine to work on in terms of my examples. Once you have multiple levels of state machines, then that kind of feature is very handy.
The syntax for regular expressions was redone, and i think its the best notation that has even been devised for that often opaque part of programming. One doesn't use them much, but they are sure hard to read in the classical Unix form.
@jdubray - You may recall that about a year ago I was contorted over how to separate View concerns from the SAM state-transition logic loop. Today it finally came to me: Put the SAM methods in a Web Worker and let the View respond to 1) events and send proposals to the SAM worker, and to 2) messages from the worker to update the DOM in the main thread.
That's a good solution, I think SAM pattern works well with actor model.
Good day, everyone. I cannot find the "old" rocket launcher example where I thought I would find an answer. Here is the question:
when a timer is counting we have to re-render the timer in a view, where should nap go in the example?
state.render = function(model) {
state.representation(model)
state.nextAction(model) ;
}In the example above render is inside state.representation(model) and if place nap check there to, thennap and nextAction could run "simultaneously".
Is this valid approach:
const sr = stateRepresentation( model )
if ( nap( sr ) ) return
render( sr )
nextAction( model )So if nap is true, there is no render, if nextAction is needed, then it is done only after render
https://github.com/jdubray/sam-samples/blob/master/inferno-rocket/index.html#L251-L255
So the queing becomes front-loaded, instead of implemented at the nap
Revisiting the above with more clarity-
Of couse a SAM "machine" only has 1 NAP function, but my project is an "cart engine" (ecommerce) that supports modular extension. Modules have an interest in implementing their own NAPs against the cart state.
The top level NAP therefore delegates responsibility to registered modules, invoking each of their NAP implementations. In effect these modules are collaborating without knowing anything about each other, but you can't just compose their actions.
This would be no problem if they only need to respond to the current state- It is only when they start to care about the "event" that led to the state change, that things become problematic. The event can be captured by the SAM machine and rendered into the current state. e.g. "itemAdded".
Child NAPs can respond to that, but of course a new cycle begins with each action, meaning the next time round, it would not be "itemAdded" anymore, and the 2nd NAP missed its chance to act.
Rocket launcher is simple because when countdown gets to 0, you stop. It's a terminating condition. But think about counting upwards, and needing something to trigger only after, when "count > 20". You need to synthesise an event like "count exceeded 20", otherwise it'll trigger in an infinite loop.
So going back to my problem - to solve the "multiple proposed actions", actions can only be queued. But from my own reading (not sure if SAM or Lamport papers) it seems like a fundamental principle that intents are strongly associated with the state from which they are raised, to the point where it seems legitimate to require a "version/sequence number" on an intent, and to reject it if the model version has changed since then.
If I start queing actions however, I break that principle... actions become deferred to be applied against future unknown states and that doesn't feel right! But I did come up with a pattern which I think addresses the problem in my use case, and would be interested to hear thoughts.
I change the wiring so that a NAP returns model proposal(s) AND a "defferedApplication" callback.
The idea is that you can define a secondary predicate, evaluated against the new state when the action is about to be applied - to determine whether it is still valid or not. i.e. return true or false.
If the change (a.k.a. Event) that caused a NAP to propose an action was "Item added to shopping cart", the "deferredApplicatoin" callback would potentially evaluate that the product was still present in the cart.
You then have one pure NAP (a single function) that happens to call out to its subscribers with the current State Representation, and collects a list of "future actions". It then looks at the current state representation for existing "futureActions", and returns a proposal equivalent to "setFutureActions" + "the action that was at the front of the queue".
In this way, you get a synchronised model with a single NAP and the queuing built into the model itself.
