-
Notifications
You must be signed in to change notification settings - Fork 59
Language design issues
Right now, atomicity boundaries and timesteps are mapped 1-to-1. Arguably, this is not flexible enough: it might be useful to allow atomic operations that span multiple timesteps. For example, a node might like to
- Receive an input event
- Update its local state
- Compute some stuff in the updated state
Without needing to account for the possibility that something else might happen between #2 and #3.
Per https://github.com/bloom-lang/bud/issues/50, state updates produced by inductive rules are not processed eagerly. This further complicates the "state update" pattern described above: to ensure that #3 happens promptly after #2, the programmer needs to arrange to send themselves an async message.
- Conclusion: Switch <+, <- to be eager, and perhaps provide some support for lazy state update if warranted.
Currently, our language semantics allow message batching, but our implementation doesn't actually utilize it. Arguably, message batching should be disallowed, on the grounds that it complicates reasoning about program behavior for a probably-not-too-significant performance improvement. Without message batching, events cannot co-occur -- this automatically avoids some easy-to-overlook race conditions. With message batching, the programmer needs to program defensively: since any number of events might co-occur, the burden is on the programmer to ensure that event handling is sufficiently isolated. Removing message batching means that two events will never co-occur by coincidence; rendezvous between async events must always be done through explicit persistence, which seems like a nice property.
- Conclusion: Don't disallow message batching, but add syntax sugar to make message queueing simpler to use, make it easier to specify an event queueing policy, and perhaps provide non-batching channels as a language primitive (https://github.com/bloom-lang/bud/issues/50).
Right now, we make a big deal about how great monotonic programs are, but we usually neglect to mention that scratches are both non-monotonic and widely used. Something should be improved here: if the analysis we are pitching only works for programs rewritten in an esoteric style (all channels explicitly persisted), something is wrong.