@@ -30,8 +30,12 @@
31\lstset{basicstyle=\ttfamily\small}
31\lstset{basicstyle=\ttfamily\small}
33−\title{Reconnect Semantics}
33+\title{An Explicit $\semRecon$ Primitive for Cloud Haskell \\ (or a Future Erlang)}
34+\author{\small \begin{tabular}{ll}
35+Edsko de Vries & Duncan Coutts \\
36+Well-Typed LLP & Well-Typed LLP \\
34−\author{Well-Typed \texttt{<edsko@well-typed.com>}}
37+\texttt{edsko@well-typed.com} & \texttt{duncan@well-typed.com}
37\section*{Introduction}
41\section*{Introduction}
@@ -382,6 +386,11 @@ on non-existing ordering guarantees). On the other hand, requiring an explicit
382reconnect to a remote node before a spawn (or similar primitive) might be
386reconnect to a remote node before a spawn (or similar primitive) might be
383confusing.
387confusing.
389+\item Another hybrid solution is to have an implicit reconnect when sending a
390+monitor notification. So, if $P$ monitors $Q$, and gets a monitor notification,
391+then it must expect potential message loss. If $P$ does not monitor $Q$ then
392+disconnects are permanent.
385\item Since Cloud Haskell supports typed channels as well as sending messages
394\item Since Cloud Haskell supports typed channels as well as sending messages
386directly to processes, we could decide not to offer any reliability guarantees
395directly to processes, we could decide not to offer any reliability guarantees
387for messages sent directly to processes, but provide reliable-ordered message
396for messages sent directly to processes, but provide reliable-ordered message