val f = m[ (String, Promise[Int]) ] // choose String and Int types arbitrarily
site(go { case f((x, promiseR)) => .... promiseR.succeed(123) ... })
val p = Promise[Int]()
f("abc", p)
val futureR = p.future
// Done. We got a future that resolves when a reply to f is sent.
Compare this with the code that is implemented currently in
Chymyst:
val f = b[String, Int]
site(go { case f(x, reply) => .... reply(123) ... })
val futureR = f.futureReply("abc") // We got a future that resolves when a reply to f is sent.
These code snippets are completely equivalent. Just a little shorter syntax.
It does not change the expressive power of the chemical machine, it's just a convenience.
If you would like to have a scala.js implementation where the
futureReply() API is the only available API for blocking molecules, that's just as good.
I'm not very familiar with how scala.js works and how to write web applications with it; do you have experience with that?
As a first step towards a scala.js implementation for
Chymyst, I would try to implement only non-blocking molecules, no thread pools, no debugging hooks, and no waiting. This would be a great first step, because a chemical machine with only non-blocking molecules is equally expressive and equally powerful when compared to a chemical machine with blocking molecules.
if your code does not use any native threads and has no dependencies on other libraries, porting to scalajs should be a cinch ;)
I do use threads, of course. Actually I use thread pools, not the bare
Thread object.
all I need is the
Pool interface, look at Pool.scala. I need a facility to schedule the execution of a closure, asynchronously.
e.g. I need to be able to do this:
val closure = x => x + 1 + veryLongCalculation(x)
pool.runClosure(closure, 123)
// runClosure returns quickly, but "closure" is scheduled and will run later, when the run loop comes to that
this can be simulated with javascript's
setTimeout() API, perhaps.
this is exactly how scalajs does it https://github.com/scala-js/scala-js/blob/master/library/src/main/scala/scala/scalajs/concurrent/QueueExecutionContext.scala
it has it's own ExecutionContext that is based on setTimeout() and all the future api can run off that.
akka.js dispatcher is probably backed by QueueExecutionContext as well
So, perhaps the first step would be to re-implement Chymyst using just
Future while keeping in mind that it is going to run in a single-threaded context.
It just schedules closures that mutate some hidden state.
For example, emitting a new non-blocking molecule means scheduling a closure that will add a new molecule copy to the soup and look for possible new reactions involving that molecule.
new reactions can be scheduled in the same way, since we are going to have one execution context for everything.
each reaction is a closure that evaluates the reaction body on the input molecule values.
it has facade that wrap regular javascript webworker api calls, but that's about it
for scalajs, the baggage (collection, utilities, etc) is quite large. it does it's best to trim the generated code but a really simple program using the optimizing output mode is still around 100KB
(assuming that webworker's code itself is really short)