You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/roadmap.md
+29-5Lines changed: 29 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,10 +34,10 @@ Version 0.2: Rework the decisions to start reactions.
34
34
In particular, do not lock the entire molecule bag - only lock some groups of molecules that have contention on certain molecule inputs (decide this using static analysis information).
35
35
This will allow us to implement interesting features such as:
36
36
37
-
- fairness with respect to molecules (random choice of input molecules for reactions)
37
+
- fairness with respect to molecules (random choice of input molecules for reactions). Not sure if this is important!
38
38
- start many reactions at once when possible
39
-
- emit many molecules at once, rather than one by one
40
-
- allow nonlinear input patterns
39
+
- emit many molecules at once, rather than one by one (not sure if this is important!)
40
+
- allow nonlinear input patterns (done in 0.1.5)
41
41
42
42
Version 0.3: Investigate interoperability with streaming frameworks such as Scala Streams, Scalaz Streams, FS2, Akka Streaming, Kafka, Heron.
43
43
@@ -110,6 +110,30 @@ Version 0.7: Static optimizations: use macros and code transformations to comple
110
110
111
111
3 * 5 - implement automatic thread fusion for singletons
112
112
113
-
3 * 3 - allow several `case` clauses in a reaction, but only when the result is a total (not partial) function that will accept any molecule values.
113
+
3 * 5 - consider whether we would like to prohibit emitting molecules from non-reaction code. Maybe with a construct such as `withMolecule{ ... }` where the special molecule will be emitted by the system? Can we rewrite tests so that everything happens only inside reactions?
114
+
115
+
3 * 3 - perhaps prohibit using explicit thread pools? It's error-prone because the user can forget to stop a pool. Perhaps only expose an API such as `withPool(...)`?
116
+
117
+
3 * 3 - implement "one-off" molecules that are emitted once (like singletons, from the reaction site itself) and never emitted again
118
+
119
+
2 * 2 - If a blocking molecule was emitted without a timeout, we don't need the second semaphore
120
+
121
+
2 * 2 - Add tests to make sure that the 2nd and all subsequent replies with .checkTimeout return False
122
+
123
+
2 * 2 - Can we consolidate all code into a single SBT project rather than use 3 projects?
124
+
125
+
3 * 3 - Can we use macros to rewrite f() into f(()) inside reactions, and thus avoid using subclasses such as E, EE, etc.?
126
+
127
+
5 * 5 - How to rewrite reaction sites so that blocking molecules are transparently replaced by a pair of non-blocking molecules? Can this be done even if blocking emitters are used inside functions? (Perhaps with extra molecules emitted at the end of the function call?) Is it useful to emit an auxiliary molecule at the end of an "if" expression, to avoid code duplication? How can we continue to support real blocking emitters when used outside of macro code?
128
+
129
+
2 * 2 - Support timers: recurrent or one-off, cancelable molecule emission
3 * 3 - How to implement "Wavefront" computations such as Game of Life efficiently with more concurrency?
134
+
135
+
3 * 3 - Replace some timed tests by probabilistic tests that run multiple times and fail much less often
114
136
115
-
3 * 5 - consider whether we would like to prohibit emitting molecules from non-reaction code. Maybe with a construct such as `withMolecule{ ... }`?
137
+
2 * 2 - If the RS is busy, leave a "bump" message and still append a molecule to a queue; or, RS can continually check the queue of new molecules until it's empty
138
+
139
+
3 * 3 - Implement "streamable" molecules, detect them automatically
0 commit comments