Write Dapps as continuous workflows

The monad will execute as off-chain Haskell code. It will be a continuous do expression that will define HTTP endpoints and will use Cardano endpoints. The result is a clear specification of the entire process as a "workflow" which is clearly readable, maintainable and verifiable.

Using the same definitions of the guess game example of the Plutus tutorial, the logic of the DApp would be, with a bit of psedocode, but basically Haskell code:

do

endpoint "1"

inChain startGame

endpoint "2"

amount - input (const True) "enter amount to lock"

inChain $ lock amount

endpoint "3"

option "g" "guess"

text - local $ input (cost True) "enter guess string"

result - inChain $ guess text

if result then do

trace "OK" ; return "OK"

-- all intermediate endpoints are erased

else trace "FAIL"; return "FAIL"

DApps involving contracts take a long time to complete. The program should support stop and recovery of the execution state at the step where it was when it was stopped.

The program can be executed as a console application or as a HTTP server, using a HTTP client. The commands option and input mean that the endpoint 3 need two parameters to continue executing, The program can get them from the request URL, from the console if they are provided in the command line or interactively. This would facilitate testing.

Since it is Haskell code, optionally it can be used for any other kind of application, for example,a mobile app.

Enforces correctness by ordering: Each endpoint is created when the program reach it, so guess is not reachable if lock has not been executed, which would not be executed if startGame has not been executed first.

Each game initiated, and each endpoint created, would have his own identifier. A endpoint will execute until the next endpoint, taking the parameters from the URL or from the console if it is executed as a command. For example to execute guess "plutus", the address would be:

http://host/[hash of endpoint 3]/g/plutus

Endpoints are executed until the next endpoint. It is the most basic way for interaction trough HTTP. It returns a HTTP 200 OK response with the address/es of the next endpoints reachable from it. There will be more variants for accepting posts, files, return JSON etc, for developing complete applications in Haskell.

Routes with alternative endpoints can be expressed with the alternative Haskell operator (I can not write the operator since the submission software interpret it as HTML tag)

code with some endpoint `alternative op` code with some endpoint ..

Managed session state: Each endpoint has in scope all the variables computed in previous steps. The session state contains all these variables and will be stored in a file, in IPFS or in Cardano metadata. If the server for these particular endpoint is stopped, the execution state will be restored and the execution will continue.

The basic elements of these functionalities: serializable continuations, HTTP interaction and endpoints are already developed in Haskell libraries. It remains to do some parts:

• inChain primitive: integration of in-chain Plutus code
• Storing and retrieving continuation state in IPFS
• Different kinds of HTTP endpoints

At least four months of work are necessary for a first version that shows his functionalities with all the elements mentioned. I'm an expert Haskell developer but a newbie in Cardano.