@@ -30,8 +30,12 @@
3030
3131\lstset{basicstyle=\ttfamily\small}
3232
33−\title{Reconnect Semantics}
34−\author{Well-Typed \texttt{<edsko@well-typed.com>}}
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 \\
37+\texttt{edsko@well-typed.com} & \texttt{duncan@well-typed.com}
38+\end{tabular}}
3539\maketitle
3640
3741\section*{Introduction}
@@ -382,6 +386,11 @@ on non-existing ordering guarantees). On the other hand, requiring an explicit
382386reconnect to a remote node before a spawn (or similar primitive) might be
383387confusing.
384388
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.
393+
385394\item Since Cloud Haskell supports typed channels as well as sending messages
386395directly to processes, we could decide not to offer any reliability guarantees
387396for messages sent directly to processes, but provide reliable-ordered message