the remote monad design pattern - github pages · call, using monads as a descriptor of remote...

The Remote Monad Design Pattern

Andy Gill Neil Sculthorpe lowast Justin Dawson Aleksander EskilsonAndrew Farmer Mark Grebe Jeffrey Rosenbluth dagger Ryan Scott James Stanton

Information and Telecommunication Technology Center University of Kansas USAfirstlastittckuedu

AbstractRemote Procedure Calls are expensive This paper demonstrateshow to reduce the cost of calling remote procedures from Haskellby using the remote monad design pattern which amortizes thecost of remote calls This gives the Haskell community access toremote capabilities that are not directly supported at a surprisinglyinexpensive cost

We explore the remote monad design pattern through six modelsof remote execution patterns using a simulated Internet of Thingstoaster as a running example We consider the expressiveness andoptimizations enabled by each remote execution model and assessthe feasibility of our approach We then present a full-scale casestudy a Haskell library that provides a Foreign Function Interfaceto the JavaScript Canvas API Finally we discuss existing instancesof the remote monad design pattern found in Haskell libraries

Categories and Subject Descriptors D32 [Programming Lan-guages] Language ClassificationsmdashApplicative (functional) lan-guages

Keywords Monads Remote Procedure Call FFI Design Pattern

1 IntroductionRemote Procedure Calls (RPCs) are expensive This paper presentsa way to make them considerably cheaper the remote monaddesign pattern Monads [34 42] provide a general way of struc-turing composite computations These monadic computations arefirst class they can be passed to functions as arguments returnedfrom functions as results and stored in data structures But monadiccomputations are not typically executed remotely

This paper investigates the ways that monadic computations canbe serialized for the purposes of being sent to remote locationsfor external execution The idea is that rather than directly calla remote procedure we instead give the remote procedure call aservice-specific monadic type and invoke the remote procedurecall using a monadic ldquosendrdquo function

lowastNow at the Department of Computer Science Swansea University UKnasculthorpeswanseaacukdaggerUnaffiliated

Definition A remote monad is a monad that has its evaluationfunction in a remote location outside the local runtime system

By factoring the RPC into sending invocation and service namewe can group together procedure calls and amortize the cost ofthe remote call To give an example Blank Canvas our libraryfor remotely accessing the JavaScript HTML5 Canvas has a sendfunction lineWidth and strokeStyle services and our remotemonad is called Canvas

send Device -gt Canvas a -gt IO alineWidth Double -gt Canvas ()strokeStyle Text -gt Canvas ()

If we wanted to change the (remote) line width the lineWidthRPC can be invoked by combining send and lineWidth

send device (lineWidth 10)

Likewise if we wanted to change the (remote) stroke colorthe strokeStyle RPC can be invoked by combining send andstrokeStyle

send device (strokeStyle red)

The key idea of this paper is that remote monadic commands canbe locally combined before sending them to a remote server Forexample

send device (lineWidth 10 gtgt strokeStyle red)

The complication is that in general monadic commands can returna result which may be used by subsequent commands For exam-ple if we add a monadic command that returns a Boolean

isPointInPath (DoubleDouble) -gt Canvas Bool

we could use the result as follows

send device $ doinside lt- isPointInPath (00)lineWidth (if inside then 10 else 2)

The invocation of send can also return a value

do res lt- send device (isPointInPath (00))

Thus while the monadic commands inside send are executed ina remote location the results of those executions need to be madeavailable for use locally

This is the authorrsquos version of the work It is posted here for your personal use Not forredistribution The definitive version was published in the following publication

Haskellrsquo15 September 3-4 2015 Vancouver BC CanadaACM 978-1-4503-3808-01509httpdxdoiorg10114528043022804311

59

2 Haskell Calling the Real WorldWhen Haskell users want an established graphics library such asOpenGL or a web-client library such as cURL they typically usea Haskell library that uses the Foreign Function Interface (FFI)capability to link Haskell code with the native capabilities of thedesired external library Rather than reimplement existing codethe rich FFI capability is used to tunnel to C and onwards toestablished libraries such as the C or C++ implementations ofOpenGL and cURL The FFI is well-supported but there are threeconceptual problems to be solved in crossing to native C libraries

1 Control flow needs to transfer to the correct C function Giventhe lowest level of the GHC runtime system is written in Ccontrol-flow transfer is straightforward

2 The data structures that are arguments and results of calls to Cneed to be marshalled into the correct format For example Cstrings are not the same as Haskell strings

3 The abstractions of the target C library may not be idiomaticHaskell abstractions For example many C++ APIs assumeOO-style class inheritance Foreign abstractions can be simu-lated in Haskell but this raises an obfuscation barrier

Any time control flow leaves the Haskell eco-system all three ofthese concerns need to be addressed All three are supported bythe Haskell FFI for C There is a way of directly promoting a Cfunction into Haskell-land there is good support for marshallingHaskell data structures into C structures as well as automaticmemory-management support and Haskell abstraction capabilitiesare used to build more Haskell-centric APIs on top of the FFIcapability However what about functions that cannot be calleddirectly but must be invoked using a remote procedure call Allthree identified FFI issues come into play

1 The control flow needs to use an RPC mechanism to establishforeign control-flow transfer This can add considerable costs Atypical mechanism would be to establish a TCPIP connectionwith a published remote service

2 The procedure arguments are sent to the remote location typi-cally over a TCPIP channel the remote command is executedand the result is communicated back

3 The remote nature of the call raises issues with presentingremoteness to the API user What does this remote functionlook like to a Haskell programmer Are the costs reflected inthe API design

In this paper we investigate a generalization of the remote procedurecall using monads as a descriptor of remote execution Specificallywe make the following contributions

bull We document a DSL pattern for bundling RPCs the remotemonad design pattern This pattern cuts the cost of RPCs inmany cases by amortizing the remote aspect and is a designpoint between classical monadic APIs and using deeply em-bedded DSLs for offline remote execution

bull Toward understanding the remote monad we give four com-plete models of remote execution (sect31 sect32 sect4 sect5) and sketchtwo useful variations of the strongest model (sect6 sect7) We give aset of remote monad laws (sect8) and observe that the pattern hasbeen used in a weak form several times before (sect11)

bull We explore the design pattern in a real-world large-scaleexample called Blank Canvas (sect9) We quantify our experi-ences and measure performance on some benchmarks com-paring native JavaScript and Blank Canvas over two operatingsystems and two web browsers (sect10)

3 Modeling Remote CommunicationFor illustration purposes we will remotely control an Internet ofThings toaster which includes a thermometer and a voice syn-thesis circuit We can ask the toaster to say things measure thetemperature or make toast for a given number of seconds Us-ing a monad called Remote we have

say String -gt Remote ()temperature Remote Inttoast Int -gt Remote ()

In the remote monad design pattern we have a way of running ourmonad remotely which we call send

send Device -gt Remote a -gt IO a

The key step in an efficient implementation of the remote monad isthe choice of packaging of commands Ideally the entire monadiccomputation argument of send would be transmitted in a singlepacket but in general this is not possible

Towards understanding the choices we are going to build sev-eral ways of interacting with our toaster

bull As a preamble in sect31 we build a basic asynchronous RPC andin sect32 we build a basic synchronous RPCbull In sect4 we build the simple version of a remote monad called

a weak remote monad where a monadic API is utilized toconceptually bundle commands for remote executionbull In sect5 we build another remote monad called a strong remote

monad where a monadic API is utilized to actually bundlecommands for more efficient remote execution This is ourprincipal model of the key idea of this paperbull In sect6 we build a remote applicative functor which exploits the

restrictions of the applicative functor operations (relative to themore expressive monadic bind) to allow for better bundlingbull Finally in sect7 we use a deep-embedding technique to add sup-

port for remote binding of non-local values again improvingthe bundling of remote primitives

In each case we implement the local behavior of the send functionas well as give a minimal implementation of remote behavior Ingeneral in the remote monad design pattern the remote executionmay be in any language Here for simplicity we simulate remoteexecution from within Haskell and use the built-in Show and Readclasses to simulate serialization and deserialization We highlightthe dual execution nature of the remote monad by using distinctdata structures locally and remotely Using distinct data structuresalso allows us to side-step the orthogonal challenge of GADTdeserialization

31 An Asynchronous Remote Command CallThis first model will be able to send single commands asyn-chronously to a remote device This model is also known as theCommand design pattern [19]

Definition A remote command is a request to perform an actionfor remote effect where there is no result value or temporal conse-quence

We use a deep embedding of the commands that we want tosend asynchronously For this simple example we only consider asingle command

data Command = Say Stringderiving Show

We derive a Show instance so that we can serialize Command inpreparation for transmitting it to a remote interpreter

60

LocalNetwork

Remote

GHCi send Command device

send

Say

Say Do you want some toast

()

Figure 1 Example of an Asynchronous Remote Command Call

We represent a remote device as a function from String toIO () wrapped in a data structure called Device which modelsthe communication channel between local and remote execution

data Device = Device async String -gt IO ()

We call the internal function async because it represents asyn-chronous communication For asynchronous commands there is noneed for a back-channel on which to return values

We can now define send which serializes a Command and thentransmits it to a remote device

send Device -gt Command -gt IO ()send d m = async d (show m)

Our Haskell simulation of the remote device requires a repre-sentation of commands on the remote device an execution functionfor those commands and a deserialization function that reads thosecommands As a convenience we use the same constructor namefor the remote command data type so that deserialization can behandled by a derived Read instance1

data RCommand = Say Stringderiving Read

execRCommand RCommand -gt IO ()execRCommand (Say str) = putStrLn (Remote ++ str)

Our device which simulates the remote interpreter handle canthen be defined as

device Devicedevice = Device (execRCommand read)

This completes our model Now we can test it by sending a Saycommand which prints remotely

GHCigt send device (Say Do you want some toast)Remote Do you want some toast

In summary this model is a direct implementation of asyn-chronous remote calls Figure 1 shows the interactions in this ex-ample invocation using a sequence diagram We take the liberty ofexpressing our construction of Command as a sequence process andwe give the serialized text sent to the remote device using greenfor an asynchronous call

32 A Synchronous Remote CallIn this subsection we build a synchronous remote call a version ofsend that can receive a reply to a remotely transmitted procedureThat is we will define a model of a remote procedure call

Definition A remote procedure is a request to perform an actionfor its remote effects where there is a result value or temporalconsequence

1 This code must be placed in a separate module to avoid a name clash

When we execute a remote procedure we either want to get aresult back (eg the measured temperature) or know that a specificremote action has been completed (eg the toast is made) In thismodel because we are interested in getting a reply we representremoteness using a function from String to IO String

data Device = Device sync String -gt IO String

As with commands we use a deep embedding of the proceduresthat we want to send However as we now expect to receive a resultin reply we use a GADT with a phantom type index denoting theexpected result type

data Procedure -gt whereTemperature Procedure IntToast Int -gt Procedure ()

As with commands we provide serialization using the Show class

deriving instance Show (Procedure a)

For deserialization we provide an auxiliary function that uses thephantom type index of Procedure to determine which Read in-stance should be used to parse the reply from the remote device

readProcedureReply Procedure a -gt String -gt areadProcedureReply (Temperature ) i = read ireadProcedureReply (Toast ) i = read i

The two read functions are each reading different types as con-strained by the specific Procedure constructor

Now we can write our send command

send Device -gt Procedure a -gt IO asend d m = do

r lt- sync d (show m)return (readProcedureReply m r)

That is send serializes the Procedure sends it over a syn-chronous channel and interprets the reply in terms of the typeof the same Procedure This time send is polymorphic in thetype parameter of Procedure and IO

Our simulated remote Device is straightforward to constructFor conciseness we have merged serialization of the result valueinto the execution function but these steps could be separated

data RProcedure = Temperature| Toast Int

deriving Read

execRProcedure RProcedure -gt IO StringexecRProcedure Temperature = do

t lt- randomRIO (50 100 Int)return (show t)

execRProcedure (Toast n) = doputStrLn (Remote Toasting)threadDelay (1000 1000 n)putStrLn (Remote Done)return (show ())

device Devicedevice = Device (execRProcedure read)

This completes our model Now we can test it by sending aTemperature procedure which returns the temperature locally

GHCigt send device Temperature56

We have taken a procedure transmitted it to a remote interpreterexecuted it remotely and returned with the result mdash thus we havea basic model of a typical Remote Procedure Call Figure 2 showsthe sequence diagram for this interaction We use red to highlightthe synchronous communication call

61

LocalNetwork

Remote

GHCi send Procedure device

send

Temperature

Temperature

56

56

56

Figure 2 Example of a Synchronous Remote Procedure Call

4 The Weak Remote MonadThus far our arguments to send have not been instances of MonadWe will now address this Here we join the asynchronous andsynchronous models into a monad called Remote In this sectionwe implement an initial version of the remote monad that does notamortize the cost of communication We call this a weak remotemonad

Definition A weak remote monad is a remote monad that sendseach of its remote calls individually to a remote interpreter

In this example the Remote monad is implemented using thereader monad where the environment is our Device nested aroundthe IO monad using monad transformers [22 27]

newtype Remote a = Remote (ReaderT Device IO a)

deriving instance Monad Remote

This gives us access to the specific Device which will allow us tosend individual commands to the remote interpreter on the fly Weuse deriving instance Monad to allow the monadic operatorsto be used while hiding the transformer-based operations inside theRemote abstraction

Device now needs to support both sync and async In a realimplementation it would be expected that there would be twoentry points into the same communication channel where the usagespecifics depend on if we want to receive a reply

data Device = Device sync String -gt IO String async String -gt IO ()

A send-style function customized for our weak Remote monadprovides remote execution for Command Observe that each com-mand invokes the remote procedure call immediately

sendCommand Command -gt Remote ()sendCommand m = Remote $ do

d lt- askliftIO (async d (show m))return ()

say String -gt Remote ()say txt = sendCommand (Say txt)

For procedures we also provide a send-style function again cus-tomized for our weak Remote monad Again each procedure in-vokes the remote procedure call immediately

LocalNetwork

Remote

GHCi send Remote device

send

say

Say Do you want some toast()

temperature

Temperature

56

56

say

Say 56F()

56

send

toast

Toast 120

()

()

()

Figure 3 Example of a Weak Remote Monad

sendProcedure Procedure a -gt Remote asendProcedure m = Remote $ do

d lt- askr lt- liftIO (sync d (show m))return (readProcedureReply m r)

temperature Remote Inttemperature = sendProcedure Temperature

toast Int -gt Remote ()toast n = sendProcedure (Toast n)

Our main send function is now used to run the Remote monadunboxing the reader function and applying it to the Device

send Device -gt Remote a -gt IO asend d (Remote m) = runReaderT m d

Finally the virtual remote Device is a combination of the syn-chronous and asynchronous Devices


(execRCommand read)

Now we can call send with a monadic argument and chains ofprimitives connected using the monad will be executed We haveachieved our original goal a (weak) remote monad where the prim-itive commands and procedures are executed in a remote location

GHCigt t lt- send device $ dosay Do you want some toastt lt- temperaturesay (show t ++ F)return t

Remote Do you want some toastRemote 56FGHCigt when (t lt 70) (send device (toast 120))Remote Toastingsleeping for 120 secondsRemote Done

Figure 3 shows the sequence diagram for this example of the weakremote monad For every primitive call invoked there is a remotecall to the device Furthermore the GHCi computation does notterminate until the toast is complete

62

5 The Strong Remote MonadWe want to bundle monadic remote calls and send them as pack-ets of computations to be remotely executed The strong remotemonad does this We have two classes of primitive remote callscommands that do not require any specific result to be observedand procedures that require a reply from the remote site

bull For commands which are asynchronous and do not send areply we can queue up the command and commit to sendingit laterbull For procedures which are synchronous we need to transmit

them immediately Thus we first send all outstanding queuedcommands then send the procedure and then await the proce-durersquos result

At the end of executing a send we flush the queue of any outstand-ing commands

This is the key idea behind a strong remote monad packagethe sequence of monadic actions into a list of commands whichare (in all but the final case) terminated by procedures This designassumes that the only primitive remote calls in our remote monadare commands and procedures and thus there is no way of locallypausing or stalling the pipeline of commands The queuing of com-mands is simply a bundling strategy for commands and proceduresthat would be executed immediately after each other anyway

Definition A strong remote monad is a remote monad that bun-dles all of its remote calls into packets of commands punctuated byprocedures for remote execution

In the strong remote monad as well as knowing what Device totalk to we need to queue up the list of to-be-transmitted CommandsWe use a reader monad for the Device (as with the weak remotemonad) and a state monad for the command queue Thus our(strong) remote monad can be defined as

newtype Remote a =Remote (ReaderT Device (StateT [Command] IO) a)

We want to send a packet of Commands terminated by a Procedureand also to have a way of sending a packet of Commands with-out a terminating Procedure For the latter case we simply send[Command] For the former case we introduce a dedicated datatype

data Packet a = Packet [Command] (Procedure a)deriving Show

Now we can start providing monadic primitives A utility func-tion sendCommand appends Commands to our ldquoto-be-sentrdquo queueand say supports the remote monad interface

sendCommand Command -gt Remote ()sendCommand cmd = Remote (modify (++ [cmd]))


Supporting procedures is more involved We need to flush the queueof outstanding Commands as well as to actually send a packetcontaining the Commands and procedure to the remote site

LocalNetwork

Remote


send

say

()

temperaturePacket [Say Do you want some toast]

Temperature

56

56

say

()

[Say 56F]

56

send

toast

Packet [] (Toast 120)

()

()

()

Figure 4 Example of a Strong Remote Monad

sendProcedure Procedure a -gt Remote asendProcedure p = Remote $ do

d lt- askcs lt- getr lt- liftIO (sync d (show (Packet cs p)))put []return (readProcedureReply p r)



Next we provide our send function which runs our inner monadand flushes any remaining Commands to the remote interpreter

send Device -gt Remote a -gt IO asend d (Remote m) = do

(rcs) lt- runStateT (runReaderT m d) []when (not (null cs)) (async d (show cs))return r

Finally we define our simulated remote device now extended withan execution function for packets

device Devicedevice = Device (execRPacket read)

(mapM_ execRCommand read)

data RPacket = Packet [RCommand] RProcedurederiving Read

execRPacket RPacket -gt IO StringexecRPacket (Packet cs p) = do

mapM_ execRCommand csexecRProcedure p

Figure 4 shows the sequence diagram for the strong remotemonad on the same example as used for the weak remote monadAs can been seen Packet combines Commands punctuated byProcedures

63

6 The Remote Applicative FunctorThere is also a remote applicative functor

Definition A remote applicative functor is an applicative functorthat has its evaluation function in a remote location outside thelocal runtime system

As with monads there are two classes the weak remote applica-tive functor and the strong remote applicative functor Without abind operator applicative functors [30] are fundamentally bettersuited to remoteness than monads are subsequent applicative com-putations cannot depend on the results of prior computations whichin our context allows for bundling of procedures In fact (using ourterminology) a strong remote applicative functor is currently usedby Facebook to bundle database requests [29]

Any weak remote monad is by definition (at least) a weakremote applicative functor with primitive calls transmitting indi-vidually More interesting is the strong remote applicative func-tor which we consider here Exploiting the independence of subse-quent calls from the results of prior calls we are going to bundle allthe Commands and Procedures together in a single packet whichwe represent by a list of Prims (primitive remote calls)

data Prim whereCommand Command -gt PrimProcedure Show a =gt Procedure a -gt Prim

deriving instance Show Prim

Our applicative functor is a wrapper around a monad transformer

newtype Remote a =Remote (WriterT [Prim] (State [String]) a)

This monad transformer is a combination of the writer monadfor accumulating queued primitive calls and the state monad forsimultaneously parsing results We will use lazy evaluation to ldquotie-the-knotrdquo [2] between these two effects in send We explicitlyprovide the instances for Applicative and Functor but notMonad

We handle Commands using the underlying writer monad

sendCommand Command -gt Remote ()sendCommand cmd = Remote (tell [Command cmd])

Handling Procedures is a bit more involved We use the writermonad to remember the Procedure then read the result from thestate lazily pulling it off a list Crucially there are not any externaleffects inside our inner monad

sendProcedure Show a =gt Procedure a -gt Remote asendProcedure p = Remote $ do

tell [Procedure p]~(rrs) lt- getput rsreturn (readProcedureReply p r)

We build send using recursive do notation [16 17] If our list ofPrims contains only Commands then we send it asynchronously toour remote device Otherwise we send it synchronously and awaitthe list of results from the remote device We then recursively feedthis result list back into the invocation of the applicative functorWhether synchronous or asynchronous we bundle the complete listof Prims as a single packet


rec let ((aps)_) = runState (runWriterT m) rr lt- if all isCommand ps

then do async d (show ps)return []

else do str lt- sync d (show ps)return (read str)

return a

LocalNetwork

Remote

Applicative Functor used to extract primitives

(56lowast ()lowast and 99lowast are unevaluated thunks at return time)


send

say

()

temperature

56lowast

toast

()lowast

temperature

99lowast [Command (Say Good Morning)

Procedure Temperature

Procedure (Toast 120)

Procedure Temperature]

[56()99]

(5699)

(Returned value used to tie the knot)

Figure 5 Example of a Strong Remote Applicative Functor

We are able to transmit Procedures as a bundle because wecannot examine the result on individual Procedures until we havethe entire applicative functor computation result mdash a key propertyof applicative functors

Our simulated remote device now needs to handle lists of inter-mingled commands and procedures

data RPrim = Command RCommand| Procedure RProcedure

deriving Read

execRPrims [RPrim] -gt IO [String]execRPrims [] = return []execRPrims (Command c ps) = do

execRCommand cexecRPrims ps

execRPrims (Procedure p ps) = dor lt- execRProcedure prs lt- execRPrims psreturn (rrs)

The device implementation uses execRPrims for both syn-chronous and asynchronous requests

device Devicedevice = Device (liftM show execRPrims read)

(void execRPrims read)

We can now transmit bundles containing both commands and pro-cedures For example we can measure the temperature before andafter toasting in one request

GHCigt (t1t2) lt- send device $liftA2 ()

(say Good Morning gt temperature)(toast 120 gt temperature)

Remote Good MorningRemote Toastingsleeping for 120 secondsRemote DoneGHCigt print (t1t2)(5699)

Figure 5 shows the sequence diagram for this example Notice howall three Procedures (and the Command) are sent to the toaster in asingle packet

64

7 Remote BindingAn alternative to combining procedures into one super-procedurewith restrictions would be to have the remote interpreter directlyuse the result of a procedure We achieve this by introducing a re-mote binding mechanism which locally acts like a remote proce-dure but remotely acts like a command To do so we use sometricks for deeply embedded DSLs To recap deep embeddings

bull We capture expressions by building data-structures that repre-sent the operations inside the expressionbull We capture functions by extending our embedding with vari-

ables [12] and applying the function to a fresh variable

As an example towards building our remote monad model con-sider appending the string ldquoFrdquo to a string

f StringExpr -gt StringExprf t = t ltgt F

We can capture f by using a small data structure for StringExprthat includes unique variables

type Id = Int

data StringExpr = Var Id| Lit String| Append StringExpr StringExpr

With suitable IsString and Monoid instances for StringExprwe can reify the function

GHCigt f (Var 0)Append (Var 0) (Lit F)

Our remote monad will use the function-capture technique bygenerating a new Id locally for each binding done remotely

Definition A remote binding is the combination of a request toperform an action for its remote effects where there is an interest-ing result value and the remote interpreter binding this result valueto a name remotely The remote action is called a remote bindee

The result of a remote binding can be used immediately withoutneeding local interaction because the result value resides remotelyLocally we generate a new and unique Id allowing the bindee tobe bundled with commands This is the trick mdash remote binders area form of remote procedure calls but because they return handleswith known identifiers we can transmit them to the remote site asremote commands

We want our Temperature procedure to now be a Bindee sothat we can directly use the result remotely We constrain the typeof an Bindee in the same way we constrained the return type of aprocedure by using a GADT

data Bindee -gt whereTemperature Bindee StringExpr

We now define the Command data type such that Say takes aStringExpr argument and with a Bind command that will re-motely bind an Id to a Bindee

data Command whereSay StringExpr -gt CommandBind Id -gt Bindee StringExpr -gt Command

We have our utility functions say and temperature and a func-tion bindBindee that locally generates a name for the remotelybound value before utilizing sendCommand

say StringExpr -gt Remote ()say txt = sendCommand (Say txt)

LocalNetwork

Remote


send

temperature

(Var 0)

say

()

reply

Packet[ Bind 0 Temperature

Say (Append (Lit The temperature is )

(Append (Var 0) (Lit F)))

] (Reply (Var 0))

56

56

56

Figure 6 Example of Remote Binding in a Strong Remote Monad

bindBindee Bindee StringExpr -gt Remote IdbindBindee e = do

i lt- newIdsendCommand (Bind i e)return i

temperature Remote StringExprtemperature = do

i lt- bindBindee Temperaturereturn (Var i)

For returning the results of remote expressions we provide aProcedure that takes a StringExpr remotely executes it andreturns the result

data Procedure -gt whereReply StringExpr -gt Procedure String

reply StringExpr -gt Remote Stringreply e = sendProcedure (Reply e)

This completes our set of transmittable primitives The remainingdefinitions are almost identical to the strong remote monad modelexcept that the Remote monad now contains a numeric state that isused for fresh name generation and the remote interpreter has anenvironment that can be updated Using the above new machineryand a suitable remote device we can now run an example

GHCigt send device $ dot lt- temperaturesay (The temperature is ltgt t ltgt F)reply t

Remote The temperature is 56F56

Figure 6 shows the sequence diagram for this example Observethat the local monadic bind has been transported to the device forremote binding

Remote bindings provide an extension of traditional serializa-tion While procedures can return anything serializable remotebindings can return handles to remote things that cannot be real-istically transmitted back to Haskell For example some languagessupport objects that when serialized lose their identity With a re-mote binding we have a handle to the original object

newtype Object = Object Int

Haskell can pass around the abstract but serializable Object andthe remote interpreter has an array of objects indexed by an integerHowever a caveat with remotely bound objects is that by creatinga handle to a remote object there is no (easy) way to know whenyou can garbage collect it

65

8 The Remote Monad LawsA remote monad is a monad that has its evaluation function in aremote location outside the local runtime system In the remotemonad design pattern this achieved by providing

bull a remote monad mdash a set of primitive commands and proceduresthat form a monad andbull a send function that facilitates remote execution of the primi-

tive commands and procedures

Towards a more systematic understanding of the remote monad wepropose the remote monad laws Consider a send specialized to aspecific destination or device d with a remote monad Remote andlocal monad Local The send function is a natural transformationbetween Remote and Local

sendd forall a Remote ararr Local a

As part of a design pattern the send function itself says nothingabout how the individual commands and procedures within theRemote monad are bundled into packets Instead as we have seensend functions can implement different bundling algorithms

We propose using the monad-transformer lift laws [22 27]also known as the monad homomorphism laws as our remotemonad laws because we are lifting the Remote computation tothe remote site by Local effect

sendd (return a) = return a (1)sendd (m gtgt= k) = sendd m gtgt= (sendd k) (2)

Assuming these laws the monad laws and the laws relating func-tors and applicative functors to monads the following morphismlaws can be derived

sendd (pure a) = pure a (3)sendd (m1 ltgt m2) = sendd m1 ltgt sendd m2 (4)sendd (fmap f m) = fmap f (sendd m) (5)

Laws (1) and (3) state that a send has no effect for pure computa-tions Laws (2) and (4) state that packets of remote commands andprocedures preserve the ordering of their effects and can be splitand joined into different sized packets without side effects Law (5)is a reflection of the fact that send captures a natural transforma-tion

81 Infinite Remote MonadsFrom observation of the laws it is straightforward to split any finitesequence of total Remote primitives into arbitrarily sized packetsIt should be possible to lift the finiteness pre-condition as follows

bull In the weak remote monad each primitive invokes an individualRPC Therefore it is completely reasonable to have an infinitestream of primitives in the Remote monad in the same way thatwe can have infinite monadic computations in the IO monadThe hArduino library discussed in sect114 is an example of thisbull In the strong remote monad it would be possible to have an

infinite stream of primitives in the Remote monad providedthe packets are themselves finite If necessary this could beartificially manufactured by putting an upper bound on thenumber of consecutive commands before sending a packet

We leave lifting the finiteness requirement of the remote applicativefunctor to future work observing that an applicative functor willlikely require Alternative or something similar to achieve aninteresting infinite denotation

82 NetworkingMaking networks robust is a hard problem For example UDPpackets are not guaranteed to arrive or arrive in order so are unsuit-able without additional infrastructure for use in a remote monadThe remote monad laws assume the network works However hav-ing all remote calls wrapped in a send allows for send to enforcea specific policy for example time-out after 3 seconds and raisean exception in the Local monad Also the Remote monad couldhave control structures for exception handling built in The advan-tage is that by having a structured way of calling remote servicesthis gives hooks to include systematic recovery services as part ofthe remote service API

83 ThreadingWe have assumed a single-threaded local user and a single-threadedremote service and the remote monad laws reflect this assumptionWe could lift the local single-threaded assumption trivially by us-ing a lock on invocations of send keeping the remote interactionssingle threaded Alternatively we could allow the local actions tobe threaded and have the thread usage reflect into the remote siteThe interleaving semantics will certainly depend on the specific re-mote monad and as when running any side-effecting command onany multi-threaded system interference patterns need to be consid-ered and accounted for

9 Extended Example Blank CanvasIn our toaster models the remote interpreter was also written inHaskell This will not be the case in general Blank Canvas is ourHaskell library that provides the complete HTML5 Canvas APIusing a strong remote monad In this section we describe how weused the remote monad design pattern to build this full scale APIthat remotely calls JavaScript

The HTML5 standard implemented by all modern web brow-sers supports a rich canvas element This canvas element providesa low-level 2-dimensional interface to the in-browser widget TheAPI provides approximately 30 methods most of which are voidmethods called for their effect and almost 20 settable attributesTable 1 gives a complete list of the base API

We name our remote monad Canvas because it representsmethods on the JavaScript Canvas From examining Figure 1all methods and all settable attributes can be transliterated intomonadic Haskell functions in our remote monad All methods andattributes are serializable values there are no callbacks in this API

Classifying the API as remote commands bindings and proce-dures is all about deciding if a specific data structure is local orremote

bull isPointInPath toDataURL and measureText are pro-cedures which return values to the Haskell runtime sys-tem returning Bool Text and TextMetrics respectively(TextMetrics is simply a wrapper around a Double)bull createLinearGradient createRadialGradient andcreatePattern are bindings because CanvasGradient andCanvasPattern are subtypes of an image class which canonly be used remotelybull ImageData is a type that is local to Haskell This is a de-

sign choice ImageData is an array of RGB byte values in-tended for pixel-level manipulations of images before callingputImageData to render to a canvas Instead of reflecting anentire deep embedding of arithmetic and array operations wemake ImageData a wrapper around a Haskell byte vector to beconstructed Haskell-side and provided as a serializable argu-ment to putImageData Thus getImageData is a procedurebull Everything else including setting attributes are commands

66

Table 1 JavaScript API for HTML5 Canvas

TRANSFORMATIONvoid save()void restore()void scale(float xfloat y)void rotate(float angle)void translate(float xfloat y)void transform(float m11float m12float m21float m22float dxfloat dy)void setTransform(float m11float m12float m21float m22float dxfloat dy)

TEXTvoid fillText(string textfloat xfloat y[Optional] float maxWidth)void strokeText(string textfloat xfloat y[Optional] float maxWidth)

TextMetrics measureText(string text)

PATHSvoid beginPath()void fill()void stroke()void clip()void moveTo(float xfloat y)void lineTo(float xfloat y)void quadraticCurveTo(float cpxfloat cpyfloat xfloat y )void bezierCurveTo(float cp1xfloat cp1yfloat cp2xfloat cp2yfloat xfloat y )void arcTo(float x1float y1float x2float y2float radius )void arc(float xfloat yfloat radiusfloat startAnglefloat endAngleboolean d)void rect(float xfloat yfloat wfloat h)

boolean isPointInPath(float xfloat y)

FONTS COLORS STYLES AND SHADOWS (ATTRIBUTES)globalAlpha float globalCompositeOperation stringlineWidth float lineCap stringlineJoin string miterLimit floatstrokeStyle any fillStyle anyshadowOffsetX float shadowOffsetY floatshadowBlur float shadowColor stringstrokeStyle any fillStyle anyfont string textAlign stringtextBaseline string

DRAWINGvoid drawImage(Object imagefloat dxfloat dy [Optional] )void clearRect(float xfloat yfloat wfloat h)void fillRect(float xfloat yfloat wfloat h)void strokeRect(float xfloat yfloat wfloat h)

STYLE ATTRIBUTESCanvasGradient createLinearGradient(float x0float y0float x1float y1)CanvasGradient createRadialGradient(float x0float y0float r0float x1float y1float r1)

CanvasPattern createPattern(Object imagestring repetition)

IMAGESstring toDataURL([Optional] string type [Variadic] any args)

ImageData createImageData(float sw float sh)ImageData getImageData(float sx float sy float sw float sh)

void putImageData(ImageData imagedata float dx float dy [Optional] )

The taxonomy of remote primitives allowed the design choice tobe an informed choice We maximize the size of our packets go-ing to the JavaScript interpreter though we flush the commandsat the end of every send We also add two meta-primitives to ourAPI sync Canvas () an empty procedure that ensures thepipeline is flushed and async Canvas () an empty com-mand that asynchronously flushes the pending commands

We used a deep embedding of the Canvas monad in BlankCanvas This is more of a historical accident at the time we wroteBlank Canvas we thought the strong remote monad required suchan embedding However as we can see from our models it ispossible to build a remote monad with a shallow embedding Thesend function interprets the embedding of the Canvas GADT

To give an example consider drawing a line using Blank Can-vas All the required primitives are commands So send bundlesthem up as a single packet and transmits the following JavaScript(without the whitespace) to the browser for evaluation

Haskell JavaScriptsend context $ do

moveTo(5050)lineTo(200100)lineWidth 10strokeStyle redstroke()

trycmoveTo(5050)clineTo(200100)clineWidth = 10cstrokeStyle = redcstroke()

catch(e) alert(rsquorsquo)

For each Blank Canvas procedure primitive we have a small wrap-per written in JavaScript that uses currying to accept a uniqueldquotransactionrdquo id in this example the number 9 and the graphicscontext c


isPointInPath(1020)tryIsPointInPath(1020)(9c)


The function $kcreply from the package kansas-comet [21]sends a JavaScript value back to the Haskell program The firstargument is the transaction id and the second argument is the

returned (JavaScript) value We then embed JavaScriptrsquosisPointInPath inside a Blank Canvas supporting function

function IsPointInPath(xy) return function (uc)

$kcreply(ucisPointInPath(xy))

For bindings we allocate a global variable and remember theunique number inside the proxy object


grd lt- 〈〈 BINDEE 〉〉

tryvar v_42 = 〈〈 BINDEE 〉〉

catch(e)alert(rsquorsquo)

In summary the JavaScript generated is a direct transliteration ofthe function calls made in Haskell using the remote monad as theguiding design pattern

10 Blank Canvas in PracticeOut of the box Blank Canvas is pac-man complete mdash it is aplatform for simple graphics classic video games and buildingmore powerful abstractions that use graphics The key question ishow well does Blank Canvas perform in practice In this sectionwe give both empirical and anecdotal evidence

101 Empirical EvidenceAn important question is the cost of using the remote monad de-sign pattern albeit over a machine-local network At first glancethe cost of using the remote monad to implement Blank Canvasseem prohibitive Blank Canvas transliterates each packet to a Textstring and then sends the packet over a network where it is parsedby the JavaScript virtual machine Normally in a JavaScript appli-cation the JavaScript program is parsed and compiled once andthe inner loops are run many times But a loop in Blank Canvaswill repeatedly transmit the contents of the loop body requiringre-parsing and re-compilation each time Even with the use of theremote monad design pattern we expect to take a significant per-formance hit above and beyond the cost of networking

67

In order to quantify our ideas we have measured the perfor-mance of Blank Canvas on several benchmark programs and com-pared them to native JavaScript We have two classes of bench-marks command benchmarks which simply render to the canvasand procedure benchmarks where the inner loop of the benchmarkinvokes some form of query that requires a round-trip from serverto client and back to the server The JavaScript versions of thebenchmarks were written in idiomatic JavaScript The Blank Can-vas tests were run using criterion [36] and the JavaScript testsused the criterion mechanism to estimate confidence

We ran our benchmarks on both Chrome and Firefox and onboth Linux and OSX The relative performance of our commandbenchmarks varied widely depending on browser and benchmarkbut on average the cost of using Haskell and the Blank Canvas APIwas between a factor of 2 and 10 relative to native JavaScript Thisis surprising and encouraging However the performance cost ofour procedure benchmarks was significantly higher up to a factorof 600 relative to native JavaScript We expect that adding a strongremote applicative functor capability would significantly reduce thecost of the procedure benchmarks because it would also allowBlank Canvas to bundle procedures We plan to perform a moresystematic study of the costs of the remote monad and the benefitsof the remote applicative functor in the future

102 Anecdotal EvidenceBlank Canvas has now been used by the students in four separateinstances of our functional programming class Students find it easyto understand given the analog between the IO monad and theremote Canvas monad with students often choosing to use BlankCanvas for their end-of-semester project To give two examplesone end-of-semester project was Omar Bari and Dain VermaakrsquosIsometric Tile Game that can be rotated in 3D in real-time anotherproject was Blankeroids a playable asteroids clone written byMark Grebe on top of Yampa [9] and yampa-canvas [39] Bothare shown here with the studentsrsquo permission

In summary Blank Canvas using the remote monad is a viableway for students to draw pictures and write games in HaskellRendering graphics uses many more commands than procedures soit (retrospectively) turns out to be an ideal candidate for the remotemonad Given that we have access to whole new capabilities weconsider the overheads of using the remote monad reasonable

11 Related WorkOnce the remote monad design pattern is understood many in-stances of its use or of related patterns can be observed in thewild In this section we discuss some of the existing instances andpresent the type of the send analog with the natural transformationhighlighted in red This list is not intended to be comprehensive butrather to give a flavor of existing uses or close uses of the remotemonad and related ideas

111 Terminal Interactionbull The ncurses [33] package provides two levels of weak remote

monads in order to provide an API for moving the cursoraround a terminal and other terminal-specific services Theouter send has the type

runCurses Curses a -gt IO a

and the inner send has the typeupdateWindow Window -gt Update a -gt Curses a

This package compiles commands into ANSI-style commandsequences to be execute directly on the terminal

112 Database Accessbull In the Haxl DSL Marlow [29] uses the properties of applicative

functors to issue database queries in parallel The send functionhas the type

runHaxl Env u -gt GenHaxl u a -gt IO a

Haxl is a DSL with a weak remote monad with a strong remoteapplicative functorbull mongoDB [23] is an API into the popular MongoDB NoSQL

database that uses a weak remote monad The send functionhas the type

access MonadIO m =gt Pipe-gt AccessMode-gt Database-gt Action m a -gt m a

113 Browser Serverbull The rather ingenious HasteApp library [10 11] is an instance

of the remote monad design pattern The HasteApp uses twoHaskell compilers a Haskell to JavaScript compiler for the lo-cal monad and GHC for the remote monad evaluator with theglue code between the two generated artifacts being automati-cally generated The send function has the type

onServer Binary a =gt Remote (Server a) -gt Client a

The Remote is a wrapper to help stage the difference betweenthe client and server compilations The Server monad is theremote monad The remoteness here is running on the serverthe main program runs on the client browserbull Sunroof is a compiler for a monadic JavaScript DSL [4 20]

developed by the University of Kansas The compiler which isconsiderably more involved than Blank Canvas could be usedstand-alone as a part of a strong remote monad There are threeseparate send commands

asyncJS SunroofEngine -gt JS t () -gt IO ()syncJS () =gt SunroofEngine -gt JS t a

-gt IO (ResultOf a)rsyncJS () =gt SunroofEngine -gt JS t a -gt IO a

Using what we have learned from studying the remote monaddesign pattern these three send functions could be combinedinto a single send

114 Embedded Systemsbull Levent Erkokrsquos hArduino package [14] uses the weak remote

monad design pattern The send-command withArduino isa one-shot operation and does not have the ability to returnvalues Instead the monad represents the whole computation tobe executed

withArduino Bool -gt FilePath -gt Arduino () -gt IO ()

68

bull Ben Gamarirsquos bus-pirate package [18] allows access to theI2C or SPI embedded device protocols via a serial port us-ing monadic primitives The send command implements theremote monad directly

runBusPirate FilePath -gt BusPirateM a-gt IO (Either String a)

bull The University of Kansas used an (as yet unpublished) strongremote applicative functor in the design of λ-bridge an inter-face between Haskell and an FPGA built on top of the openWishbone [35] bus protocol

send Board -gt BusCmd a -gt IO (Maybe a)

The applicative functor structure allows multiple reads andwrites to be combined into a bus transaction and executed onan FPGA

115 GUIsbull Heinrich Apfelmusrsquo threepenny-gui [1] uses a user-interface

element monad UI as a weak remote monad

runUI Window -gt UI a -gt IO a

116 GPGPUsbull The popular accelerate package [7] uses a remote array

design pattern to program a GPGPU The send function takesan Acc and returns a pure result

runIn Arrays a =gt Context -gt Acc a -gt a

This version of send does not use a local monad but it canbe considered to use the Identity monad The send functioncan be purely functional specifically because the computationsthat are performed remotely are purely functional Like otheruses of the remote design pattern Acc encodes the computationto be performed in this case on the GPGPU Acc is a DSLwhich provides array-based operators such as zipWith andmap There is no applicative apply or monadic bind for Acc

117 SMT solversbull Levent Erkokrsquos sbv package [15] provides access to SMT

solvers and uses a weak remote monad as its lowest level APIrunSymbolicrsquo SBVRunMode -gt Symbolic a -gt IO (a Result)

118 Gamesbull Douglas Burkersquos mcpi package [5] uses a weak remote monad

to allow Haskell users to interact with a Minecraft serverrunMCPI MCPI a -gt IO a

119 Other Related WorksThis work is the marriage of Domain Specific Languages andRemote Procedure Calls Both have a long and rich history

Sun Microsystems implemented the first widely-distributedRPC implementation [31 32] The ideas were based on Birrelland Nelsonrsquos seminal work in this area [3] All modern operatingsystems include RPC capabilities building on these initial imple-mentations There is now an array of high-level libraries and frame-works for almost any modern language offering RPC services suchas D-Bus [28] which operates within a single machine and JavarsquosJini now called Apache River (httpriverapacheorg)The Haskell cloud-computing effort [13] includes support forRPCs and can be considered such a middleware solution Thereare also many low-level protocols for executing RPCs such asJSON-RPC (httpwwwjsonrpcorg)

Domain Specific Languages are Haskellrsquos forte There are shal-lowly embedded DSLs [25 26] with direct execution and deeplyembedded DSLs [12] with a generated structure representing thecomputation and a paired evaluator There are also tagless-finalDSLs [6] where there is no early commitment to a specific embed-ding but instead class overloading in used to specify the API Sev-eral Haskell DSLs including Feldspar [37] and Obsidian [8] reifythe structure of monadic code [40 41] to generate external impera-tive code Other DSLs including CoPilot [38] and Ivory [24] use ashallow embedding of statements to capture the monadic structureAll of these DSLs could leverage the remote monad design pattern

12 Conclusion and Future WorkThis work was inspired by the question of what would an onlineevaluator of a deeply embedded DSL outside the Haskell heaplook like However as we have seen other DSL technologies canbe used to generate the remote packets the remote monad ideasare orthogonal to specific DSL implementation technologies Wethought we were writing a paper about deeply embedded DSLsand interesting GADT encodings Instead we discovered a designpattern and a small language for RPC APIs

We have built a number of remote monads and remote applica-tive functors Aside from the examples already documented abovewe have also reimplemented the Minecraft API found in mcpi butwith a strong remote monad and a general JSON-RPC frameworkin Haskell In particular the JSON-RPC protocol supports multi-ple batched calls as well as individual calls Currently the userneeds to choose between the monadic and applicative functor APIWe will use this prototype as a test-bench to explore the combina-tion of simultaneously being a strong remote monad and a strongremote applicative functor The recent push to add applicative func-tor do-notation as a GHC-extension is something that we can takeadvantage of here

Our simulated remote interpreters used regular data structuresrather than sharing the GADT used by send This was for claritybut also to avoid the complications of reifying GADTs This is nota fundamental limitation we have also implemented all our modelsusing GADTs for the remote procedures using a wrapper GADTcalled Transport to enable deserialization

data Transport (m -gt )= forall a (Show a) =gt Transport (m a)

By providing a Read instance for Transport we can hide thephantom type index from the Read instance while ensuring thatwe have a Show instance for the phantom type We expect that anyfull-scale implementation would use similar techniques when theremote interpreter uses Haskell

A remote monad is a sweet spot between an RPC and a deeplyembedded DSL offering the possibility of rich FFIs for little effortand runtime cost The remote monad design pattern allows a pro-gression from weak to strong to deep embedding giving a gentlerpathway to implement deeply embedded DSLs We have used theremote monad design pattern many times and hope others will findthe pattern as useful as we have

AcknowledgmentsWe would like to thank Heinrich Apfelmus Conal Elliott and Lev-ent Erkok for their useful discussions and insights and the anony-mous reviewers for their useful and constructive comments Thismaterial is based upon work supported by the National ScienceFoundation under Grant No 1117569 and Grant No 1350901Aleksander Eskilson Ryan Scott and James Stanton were sup-ported by the NSF REU initiative The icons in the sequence di-agrams were created by Tomoyuki Miyano and made available on-line at httpiconarchivecom

69

References[1] H Apfelmus Hackage package threepenny-gui-0602 2015[2] R Bird Using circular programs to eliminate multiple traversals of

data Acta Informatica 21(3)239ndash250 1984[3] A D Birrell and B J Nelson Implementing remote procedure calls

Transactions on Computer Systems 2(1)39ndash59 1984[4] J Bracker and A Gill Sunroof A monadic DSL for generat-

ing JavaScript In International Symposium on Practical Aspectsof Declarative Languages volume 8324 of LNCS pages 65ndash80Springer 2014

[5] D Burke Hackage package mcpi-0012 2014[6] J Carette O Kiselyov and C Shan Finally tagless partially evalu-

ated Tagless staged interpreters for simpler typed languages Journalof Functional Programming 19(05)509ndash543 2009

[7] M M T Chakravarty R Clifton-Everest G Keller S Lee B LeverT L McDonell R Newtown and S Seefried Hackage packageaccelerate-01510 2015

[8] K Claessen M Sheeran and B J Svensson Expressive array con-structs in an embedded GPU kernel programming language In Work-shop on Declarative Aspects and Applications of Multicore Program-ming pages 21ndash30 ACM 2012

[9] A Courtney H Nilsson and J Peterson The Yampa arcade InHaskell Workshop pages 7ndash18 ACM 2003

[10] A Ekblad Hackage package haste-compiler-0444 2015[11] A Ekblad and K Claessen A seamless client-centric programming

model for type safe web applications In Haskell Symposium pages79ndash89 ACM 2014

[12] C Elliott S Finne and O de Moor Compiling embedded languagesJournal of Functional Programming 13(3)455ndash481 2003

[13] J Epstein A P Black and S Peyton Jones Towards Haskell in thecloud In Haskell Symposium pages 118ndash129 2011

[14] L Erkok Hackage package hArduino-09 2014[15] L Erkok Hackage package sbv-44 2015[16] L Erkok and J Launchbury Recursive monadic bindings In In-

ternational Conference on Functional Programming pages 174ndash185ACM 2000

[17] L Erkok and J Launchbury A recursive do for Haskell In HaskellWorkshop pages 29ndash37 ACM 2002

[18] B Gamari Hackage package bus-pirate-062 2015[19] E Gamma R Helm R Johnson and J Vlissides Design Patterns

Elements of Reusable Object-Oriented Software Addison Wesley1994

[20] A Gill and J Bracker Hackage package sunroof-server-0212014

[21] A Gill and A Farmer Hackage package kansas-comet-0312014

[22] A Gill and R Paterson Hackage package transformers-04302015

[23] T Hannan Hackage package mongoDB-205 2015

[24] P C Hickey L Pike T Elliott J Bielman and J Launchbury Build-ing embedded systems with embedded DSLs In International Con-ference on Functional Programming pages 3ndash9 ACM 2014

[25] P Hudak Modular domain specific languages and tools In Inter-national Conference on Software Reuse pages 134ndash142 IEEE Press1998

[26] D Leijen and E Meijer Domain specific embedded compilers InConference on Domain-Specific Languages pages 109ndash122 ACM1999

[27] S Liang P Hudak and M Jones Monad transformers and modularinterpreters In Symposium on Principles of Programming Languagespages 333ndash343 ACM 1995

[28] R Love Get on the D-BUS Linux Journal 2005(130)3 2005

[29] S Marlow L Brandy J Coens and J Purdy There is no forkAn abstraction for efficient concurrent and concise data access InInternational Conference on Functional Programming pages 325ndash337 ACM 2014

[30] C McBride and R Paterson Applicative programming with effectsJournal of Functional Programming 181ndash13 2008

[31] S Microsystems RPC Remote procedure call protocol specificationTechnical report RFC 1050 Apr 1988

[32] S Microsystems RPC Remote procedure call protocol specificationVersion 2 Technical report RFC 1057 June 1988

[33] J Millikin Hackage package ncurses-0211 2014

[34] E Moggi Computational lambda-calculus and monads In Symposiumon Logic in Computer Science pages 14ndash23 IEEE Press 1989

[35] OpenCores Organization Wishbone B4 WISHBONE System-on-Chip(SoC) Interconnection Architecture for Portable IP Cores 2010 URLhttpopencoresorgopencoreswishbone

[36] B OrsquoSullivan Hackage package criterion-1100 2015

[37] A Persson E Axelsson and J Svenningsson Generic monadicconstructs for embedded languages In Symposium on Implementationand Application of Functional Languages volume 7257 of LNCSpages 85ndash99 Springer 2012

[38] L Pike N Wegmann S Niller and A Goodloe A do-it-yourselfhigh-assurance compiler In International Conference on FunctionalProgramming pages 335ndash340 ACM 2012

[39] N Sculthorpe Hackage package yampa-canvas-02 2014

[40] N Sculthorpe J Bracker G Giorgidze and A Gill The constrained-monad problem In International Conference on Functional Program-ming pages 287ndash298 ACM 2013

[41] J Svenningsson and B J Svensson Simple and compositional reifi-cation of monadic embedded languages In International Conferenceon Functional Programming pages 299ndash304 ACM 2013

[42] P Wadler Comprehending monads In Conference on LISP andFunctional Programming pages 61ndash78 ACM 1990

70

Introduction

Haskell Calling the Real World

Modeling Remote Communication

An Asynchronous Remote Command Call

A Synchronous Remote Call

The Weak Remote Monad

The Strong Remote Monad

The Remote Applicative Functor

Remote Binding

The Remote Monad Laws

Infinite Remote Monads

Networking

Threading

Extended Example Blank Canvas

Blank Canvas in Practice

Empirical Evidence

Anecdotal Evidence

Related Work

Terminal Interaction

Database Access

Browser Server

Embedded Systems

GUIs

GPGPUs

SMT solvers

Games

Other Related Works

Conclusion and Future Work

2 Haskell Calling the Real WorldWhen Haskell users want an established graphics library such asOpenGL or a web-client library such as cURL they typically usea Haskell library that uses the Foreign Function Interface (FFI)capability to link Haskell code with the native capabilities of thedesired external library Rather than reimplement existing codethe rich FFI capability is used to tunnel to C and onwards toestablished libraries such as the C or C++ implementations ofOpenGL and cURL The FFI is well-supported but there are threeconceptual problems to be solved in crossing to native C libraries

1 Control flow needs to transfer to the correct C function Giventhe lowest level of the GHC runtime system is written in Ccontrol-flow transfer is straightforward

2 The data structures that are arguments and results of calls to Cneed to be marshalled into the correct format For example Cstrings are not the same as Haskell strings

3 The abstractions of the target C library may not be idiomaticHaskell abstractions For example many C++ APIs assumeOO-style class inheritance Foreign abstractions can be simu-lated in Haskell but this raises an obfuscation barrier

Any time control flow leaves the Haskell eco-system all three ofthese concerns need to be addressed All three are supported bythe Haskell FFI for C There is a way of directly promoting a Cfunction into Haskell-land there is good support for marshallingHaskell data structures into C structures as well as automaticmemory-management support and Haskell abstraction capabilitiesare used to build more Haskell-centric APIs on top of the FFIcapability However what about functions that cannot be calleddirectly but must be invoked using a remote procedure call Allthree identified FFI issues come into play

1 The control flow needs to use an RPC mechanism to establishforeign control-flow transfer This can add considerable costs Atypical mechanism would be to establish a TCPIP connectionwith a published remote service

2 The procedure arguments are sent to the remote location typi-cally over a TCPIP channel the remote command is executedand the result is communicated back

3 The remote nature of the call raises issues with presentingremoteness to the API user What does this remote functionlook like to a Haskell programmer Are the costs reflected inthe API design

In this paper we investigate a generalization of the remote procedurecall using monads as a descriptor of remote execution Specificallywe make the following contributions

bull We document a DSL pattern for bundling RPCs the remotemonad design pattern This pattern cuts the cost of RPCs inmany cases by amortizing the remote aspect and is a designpoint between classical monadic APIs and using deeply em-bedded DSLs for offline remote execution

bull Toward understanding the remote monad we give four com-plete models of remote execution (sect31 sect32 sect4 sect5) and sketchtwo useful variations of the strongest model (sect6 sect7) We give aset of remote monad laws (sect8) and observe that the pattern hasbeen used in a weak form several times before (sect11)

bull We explore the design pattern in a real-world large-scaleexample called Blank Canvas (sect9) We quantify our experi-ences and measure performance on some benchmarks com-paring native JavaScript and Blank Canvas over two operatingsystems and two web browsers (sect10)

3 Modeling Remote CommunicationFor illustration purposes we will remotely control an Internet ofThings toaster which includes a thermometer and a voice syn-thesis circuit We can ask the toaster to say things measure thetemperature or make toast for a given number of seconds Us-ing a monad called Remote we have

say String -gt Remote ()temperature Remote Inttoast Int -gt Remote ()

In the remote monad design pattern we have a way of running ourmonad remotely which we call send

send Device -gt Remote a -gt IO a

The key step in an efficient implementation of the remote monad isthe choice of packaging of commands Ideally the entire monadiccomputation argument of send would be transmitted in a singlepacket but in general this is not possible

Towards understanding the choices we are going to build sev-eral ways of interacting with our toaster

bull As a preamble in sect31 we build a basic asynchronous RPC andin sect32 we build a basic synchronous RPCbull In sect4 we build the simple version of a remote monad called

a weak remote monad where a monadic API is utilized toconceptually bundle commands for remote executionbull In sect5 we build another remote monad called a strong remote

monad where a monadic API is utilized to actually bundlecommands for more efficient remote execution This is ourprincipal model of the key idea of this paperbull In sect6 we build a remote applicative functor which exploits the

restrictions of the applicative functor operations (relative to themore expressive monadic bind) to allow for better bundlingbull Finally in sect7 we use a deep-embedding technique to add sup-

port for remote binding of non-local values again improvingthe bundling of remote primitives

In each case we implement the local behavior of the send functionas well as give a minimal implementation of remote behavior Ingeneral in the remote monad design pattern the remote executionmay be in any language Here for simplicity we simulate remoteexecution from within Haskell and use the built-in Show and Readclasses to simulate serialization and deserialization We highlightthe dual execution nature of the remote monad by using distinctdata structures locally and remotely Using distinct data structuresalso allows us to side-step the orthogonal challenge of GADTdeserialization

31 An Asynchronous Remote Command CallThis first model will be able to send single commands asyn-chronously to a remote device This model is also known as theCommand design pattern [19]

Definition A remote command is a request to perform an actionfor remote effect where there is no result value or temporal conse-quence

We use a deep embedding of the commands that we want tosend asynchronously For this simple example we only consider asingle command

data Command = Say Stringderiving Show

We derive a Show instance so that we can serialize Command inpreparation for transmitting it to a remote interpreter

60

LocalNetwork

Remote


send

Say


()

































deriving Read








61

LocalNetwork

Remote


send

Temperature

Temperature

56

56

56















LocalNetwork

Remote


send

say


temperature

Temperature

56

56

say

Say 56F()

56

send

toast

Toast 120

()

()

()










(execRCommand read)





62















LocalNetwork

Remote


send

say

()


Temperature

56

56

say

()

[Say 56F]

56

send

toast


()

()

()
















63




















return a

LocalNetwork

Remote




send

say

()

temperature

56lowast

toast

()lowast

temperature





[56()99]

(5699)






deriving Read












64







type Id = Int













LocalNetwork

Remote


send

temperature

(Var 0)

say

()

reply




] (Reply (Var 0))

56

56

56
















65
























66





































67




























68



























69










































70

Introduction








Remote Binding



Networking

Threading



Empirical Evidence

Anecdotal Evidence

Related Work


Database Access

Browser Server

Embedded Systems

GUIs

GPGPUs

SMT solvers

Games

Other Related Works


LocalNetwork

Remote


send

Say


()

































deriving Read








61

LocalNetwork

Remote


send

Temperature

Temperature

56

56

56















LocalNetwork

Remote


send

say


temperature

Temperature

56

56

say

Say 56F()

56

send

toast

Toast 120

()

()

()










(execRCommand read)





62















LocalNetwork

Remote


send

say

()


Temperature

56

56

say

()

[Say 56F]

56

send

toast


()

()

()
















63




















return a

LocalNetwork

Remote




send

say

()

temperature

56lowast

toast

()lowast

temperature





[56()99]

(5699)






deriving Read












64







type Id = Int













LocalNetwork

Remote


send

temperature

(Var 0)

say

()

reply




] (Reply (Var 0))

56

56

56
















65
























66





































67




























68



























69










































70

Introduction








Remote Binding



Networking

Threading



Empirical Evidence

Anecdotal Evidence

Related Work


Database Access

Browser Server

Embedded Systems

GUIs

GPGPUs

SMT solvers

Games

Other Related Works


LocalNetwork

Remote


send

Temperature

Temperature

56

56

56















LocalNetwork

Remote


send

say


temperature

Temperature

56

56

say

Say 56F()

56

send

toast

Toast 120

()

()

()










(execRCommand read)





62















LocalNetwork

Remote


send

say

()


Temperature

56

56

say

()

[Say 56F]

56

send

toast


()

()

()
















63




















return a

LocalNetwork

Remote




send

say

()

temperature

56lowast

toast

()lowast

temperature





[56()99]

(5699)






deriving Read












64







type Id = Int













LocalNetwork

Remote


send

temperature

(Var 0)

say

()

reply




] (Reply (Var 0))

56

56

56
















65
























66





































67




























68



























69










































70

Introduction








Remote Binding



Networking

Threading



Empirical Evidence

Anecdotal Evidence

Related Work


Database Access

Browser Server

Embedded Systems

GUIs

GPGPUs

SMT solvers

Games

Other Related Works
















LocalNetwork

Remote


send

say

()


Temperature

56

56

say

()

[Say 56F]

56

send

toast


()

()

()
















63




















return a

LocalNetwork

Remote




send

say

()

temperature

56lowast

toast

()lowast

temperature





[56()99]

(5699)






deriving Read












64







type Id = Int













LocalNetwork

Remote


send

temperature

(Var 0)

say

()

reply




] (Reply (Var 0))

56

56

56
















65
























66





































67




























68



























69










































70

Introduction








Remote Binding



Networking

Threading



Empirical Evidence

Anecdotal Evidence

Related Work


Database Access

Browser Server

Embedded Systems

GUIs

GPGPUs

SMT solvers

Games

Other Related Works





















return a

LocalNetwork

Remote




send

say

()

temperature

56lowast

toast

()lowast

temperature





[56()99]

(5699)






deriving Read












64







type Id = Int













LocalNetwork

Remote


send

temperature

(Var 0)

say

()

reply




] (Reply (Var 0))

56

56

56
















65
























66





































67




























68



























69










































70

Introduction








Remote Binding



Networking

Threading



Empirical Evidence

Anecdotal Evidence

Related Work


Database Access

Browser Server

Embedded Systems

GUIs

GPGPUs

SMT solvers

Games

Other Related Works








type Id = Int













LocalNetwork

Remote


send

temperature

(Var 0)

say

()

reply




] (Reply (Var 0))

56

56

56
















65
























66





































67




























68



























69










































70

Introduction








Remote Binding



Networking

Threading



Empirical Evidence

Anecdotal Evidence

Related Work


Database Access

Browser Server

Embedded Systems

GUIs

GPGPUs

SMT solvers

Games

Other Related Works

























66





































67




























68



























69










































70

Introduction








Remote Binding



Networking

Threading



Empirical Evidence

Anecdotal Evidence

Related Work


Database Access

Browser Server

Embedded Systems

GUIs

GPGPUs

SMT solvers

Games

Other Related Works






































67




























68



























69










































70

Introduction








Remote Binding



Networking

Threading



Empirical Evidence

Anecdotal Evidence

Related Work


Database Access

Browser Server

Embedded Systems

GUIs

GPGPUs

SMT solvers

Games

Other Related Works





























68



























69










































70

Introduction








Remote Binding



Networking

Threading



Empirical Evidence

Anecdotal Evidence

Related Work


Database Access

Browser Server

Embedded Systems

GUIs

GPGPUs

SMT solvers

Games

Other Related Works




























69










































70

Introduction








Remote Binding



Networking

Threading



Empirical Evidence

Anecdotal Evidence

Related Work


Database Access

Browser Server

Embedded Systems

GUIs

GPGPUs

SMT solvers

Games

Other Related Works











































70

Introduction








Remote Binding



Networking

Threading



Empirical Evidence

Anecdotal Evidence

Related Work


Database Access

Browser Server

Embedded Systems

GUIs

GPGPUs

SMT solvers

Games

Other Related Works


the remote monad design pattern - github pages · call, using monads as a descriptor of remote...

Documents