notes-computer-jasper-jasperHandler

message handling as a generalization of exception handling:

• the handler tree can have parallel branches in which each branch can handle the message, in addition to serial chains in which one a message is caught, it is not passed further back unless it is rethrown
• the call stack is just one handler tree; others can exist simultaneously
• not all messages are exceptions; uncaught exceptions cause termination with a stack trace, but non-exception types of messages can be uncaught with no effect, or may have other effects if uncaught
• like golang defer and like ScopeGuard?, handlers for a scope may be introduced in the middle of that scope, not just in a separate block like 'except'
• more expressive pattern matching to see if a message is caught
• messages are 'resumable', and in fact if resuming the thrower can specify whether it wants to wait for the message to be handled (or not handled) (blocking), or whether to continue executing in parallel (non-blocking resumable)
• message handlers might not fire until they receive multiple messages, e.g. they have 'receptors' to which 'ligands' (the messages) attach, and they might have responses that are gated by the conjunction of multiple different receptor types
• rather than being a single event, a 'message' might be a condition variable controlled by the thrower, e.g. "condition A is now true" and then later, "condition A is now false". This fits in with the conjunction of multiple different receptor types bit above.

structured programming as a specialization of message passing:

• 'return' is a non-resumable (and hence blocking) message up the call stack which is caught by the next statement/enclosing expression after the function call site

message passing should also be integrated with pub/sub and with http://nanomsg.org/ or something like it

e.g. message passing is also part of our event-driven programming model

you might want to subscribe to a message emission location (e.g. the way that upper parts of the call stack subscribe to exceptions thrown by their descendents), and/or you might want to subscribe to a message type (e.g. the way that a marketing system might subscribe to a NewUserSignup? message, or a logging system might subscribe to all exceptions). And perhaps some intersection of these.

Design todos for jasper handlers:

• subtext was doing spreadsheet-type stuff and ran into problems and had to make a formal type and effect model; see what they came up up

Design toreads for jasper handlers:

• nanomsg
• Should look at how Smalltalk and Erlang and other Actor Model guys filter incoming messages.

See also [1].