Everything about these libraries that makes everithing infinitely composable https://github.com/transient-haskell/transient/blob/master/README.md
Another addition is tmaskwich protect from asyncronous exceptions. The pattern is:
do
resource <- tmask $ do
res <- openResource
onFinish $ \_ -> closeResource res
return res
code that uses resource
....This is equivalent to bracket openResource closeResource $ code that uses resource but works for multithreading and any other effect.
We can could isolate this pattern as a primitive openClose:
openClose :: (TransIO a) (a -> TransIO ()) -> TransIO a
openClose open close= tmask $ do
res <- open
onFinish $ \_ -> close res
return resThis is similar to the openClose that I defined time ago, but this one works for multiple threads.
open is a TransIO computation that return a "stream" of resources opened, they will be closed by onFinish when the three of threads generated after each one of them have been exhausted? It should work, but I haven´t checked it.
One advantage of the composability of transient is that any pattern is a function call wich is composable. Instead, bracket does not compose. I can open/close a resource in a thread and compose it with another open/close operation so that the continuation will work with both handles:
do
handle <- (abduce >> openClose open1 close1) <|> openClose open2 close2
computationWith handleSince computationWith is not "sequestered" and managed by openClose. Instead, bracket, which is the openClose of IO, is a "framework" in the sense that captures your computation and execute it within his own environment. Later, it return a final value, but the process has been captured in the internals of bracket. That makes your captured computation second class.
initNode
The hell of callbacks and web handlers are an hindrance for this purpose. As any modern multiplayer application, smart contracts are plagued by callbacks and handlers that break the flow and makes the specification flow to be unrecognizable in the code. The code of the server is called back from the cardano machine and from web clients.
Look at the implementation of a smart contract in Haskell, the guess game. Since cardano smart contracts are in the initial stages, plutus is a moving target. The current implementation differ in significant ways. Enter the plutus playground select the game example, which is the current implementation of the guess game.
It involves two players Player 1 thinks of a secret word and uses its hash, and the game validator script, to lock some funds (the prize) in a pay-to-script transaction output. Player 2 guesses the word by attempting to spend the transaction output. If the guess is correct, the validator script releases the funds. If it isn't, the funds stay locked.
Hardly you can see the flow of this specification in the code in either of the two implementations. And that is only the code that run in the cardano virtual machine. The interface with the user is generated by the simulator, but in a real application need his own set of handlers for web clients among other things.
Moreover this is a very simple smart contract has only two players with one step each one. A contract may involve many roles (buyer, seller, arbitrator, evaluator etc) and many steps (milestones,time intervals, validations,payments). It should be necessary to express the program like the textual specification, as a sequence of steps.
That problem is being tried to address by Marlowe. it is a high level DSL in which the contract flow can be expressed plainly without breaks of the flow. it can be analyzed statically so that some good properties could be guaranteed. It can then compiled to plutus in the future (see this paper), to create all the cardano endpoints necessary. The user interface is a task open for the DApp implementor. What the marlowe definition for the guess game would generate would be the plutus code that we see in the plutus playgroud.
The Marlowe language however has not the flexibility of Haskell.
That is how the game would look like using what I will develop. The program integrates the cardano endpoints "lock" "guess" and "startGame" defined above, although "startGame" seems not necessary in the current implementation. That is: it integrates the plutus code in a coherent workflow that integrates also the interactions with web clients:
main= keep $ do
amount <- webpoint "enter the amount to lock" -- display the path/$d as parameter of the REST call from the type of the response
-- and the path.
-- also, it read it from the console if executed in console
-- generates {"msg"="enter the amount to lock","url"= "https://servername/e/f/w/$d"}
gameId <- local $ inChain startGame
local $ inChain $ lock amount
newFlow gameId -- set a game identifier
guessText <- webPoint "enter guess text" -- generates{msg="enter guess text". "url"="https://servername/<gameId>/$d" }
-- and input it from console
result <- inChain $ guess guessText -- the inChain code of "guess" also pay if it is correct
if result
then
removeFlow gameId
webPoint "OK"
else
webPoint "FAIL"
from type to input:
class Input a where
inputIt :: a -> TransIO aThere are some new primitives: webpoint inChain newFlow. The program can be executed as a console application and as a web server. as console application it display the the webpoints URLs and ask in the console for the fields asked for. In web mode, the users can send requests to these URLs. The responses are JSON registers that contains a message AND the URL of the continuation, with placeholders for the variables required and the type expected so that the flow will continue.
The newFlow will create the identifier of the guess game that the first user has created when he locked the money in the blockchain with the previous execution of inChain startGame. The next webPoint will return the address of the flow created by the first player "https://servername/<gameId>/$d" where $d is the placeholder for the guess number. That is the continuation of the program. The first user then can publish that URL by other means to let users know that free money is available for them if they participate.
when a webPoint is invoked the program run until the next webPoint. They are basically the teleport primitive that return a message besides his URL in a JSON register.
When that URL is invoked with a number, the program will execute inChain guess guessText the guess code in the cardano blockchain. This code also pay the user in case the number is right. In this case, the flow is deleted, that means that any further invocation of the guess URL will result in a error.
Many consideration for this code: It is multuser. There are code executed by different users as is required. the sequence of the contract is clearly seen. But there more subtle things: The execution of a typical smart contract could take months or years and requires only a few interactions, so it is not guaranteed that the program will run continuously and it would be a waste of resources to maintain all the context in memory for so much time waiting for a user input. Each webPoint is a continuation which works as a web endpoint waiting for some HTTP request. After a timeout, that continuation is saved to disk and removed from memory. When the request arrives, the continuation is restored in memory and executed.
The code will run in console mode so that rapid testing of the program execution could be possible. The endpoint URLs are automatically generated.
inChain is the react primitive with some additions to interact with the cardano blockchain.
Plutus has a very sophisticated test system based on QuickCheck. However, it is complex . There are no intrinsic notion of sequence in quickCheck, so guess actions can be invoked before lock actions, two locks can come in sequence and hang the off-chain code because gameId has been coded as a global variable (Which is an easy temptation when there are no stack available and so on. these errors are spurious and does not appear in real usage scenarios, but forces the quckCheck programmer to add additional code to to emulate a logical test flow.
In my proposal the very same program can perform tests by adding a third execution model the "test mode", bt injecting values in the webPoints and using plain assert lines to perform checks of consistency.
The first is very easy since the TransIO monad is nondeterministic, so I can inject a set of values using choose or even random values. So that what is a single threaded program can perform a battery of tests.
So webPoint woud do:
webPoint = do
if there is a connection open work as a HTTP endpoint
else if test mode, inject a battery of values, using the QuickCheck.Arb instance and `choose`
else input the values expected from the console using a Input classThe rest is a matter of adding a assert and guard to verify properties and filter values for the tests.
Since the flow of the program is the flow of the specification, there are no irrelevant test cases.
to inject a set of values instead of a single value, we can use the Arbitrary class of QuickCheck combined with the non-determinism of Transient:
amount<- threads 0 $ choose $ repeat 100 $ ungen arbitrary
-- will inject 100 arbitrary values
guessValue <- threads 0 $ choose......
guard condition -- filter
assert condition -- check conditionsThat's the schema for testing. assert could use the same checks used in the quickCheck example, but the construction of sequencing by an ad-hoc state monad and the filtering of spurious sequences are not necessary.
This is possible because Transient has all the effects necessary. In this case, non determinism. The QuickCheck infrastructure need a few different monads: the spec monad and the dynamic logic monad. Besides the monads in which the production program will be coded.
The first is an state monad that implement state transitions in the context of random sequences of in-chain actions (lock and guess in this example). Since this is not a natural usage case (lock should be used once at the beginning), the tester has to introduce auxiliary code to deal with spurious errors that are not present in the real contexts.
The second, the DL monad, introduces nondeterminism to feed curated sequences of actions. This is a more realistic environment. However it only test the smart contract, not the whole logic of the program in which the smart contract may be embedded in.
Besides the monads in which the production program will be coded, the programmer has emulated partially the execution flow two more times with these two monads.
Instead, having the whole program expressed in a continuous flow allows for testing the smart contract with all the other logic together and do it once for production and testing, since the assert statements can be keept in production and the genetation of test cases can be a functionality of webPoint when run in test mode.
input is a vintage name used in early languages. Looks hateful for functional programmers. I love it.
As said above, to allow for computations whose lifespan is longer than the time between machine shutdowns, it is necessary to store and restore the execution state. I already had serialization of execution states in order to transfer them between nodes and I also had
checkpoint and restoreto store in permanent storage the execution state, but I had to program the restoration of the execution state when a request arrives and to restore also the continuations that are watching from incoming requests in the execution path, including the one which waits for the current incoming request.
mwatch :: IO (StreamData a) -> Cloud a similar to parallel but in the Cloud Monad, with the added capability of being activated when the program starts no matter where the mwatch sentectes are located in the code
Serializable Haskell continuations
The basic functionality of all that I want to do is to serialize haskell continuations incrementally so that from a cold start I can invoke any of these continuations. In this video I try to explain it:
https://www.youtube.com/watch?v=MqmDxwa61fY
data HI=HI deriving (Read,Show,Typeable)
data HELLO=HELLO deriving (Read,Show,Typeable)
data WORLD=WORLD deriving (Read,Show,Typeable)
instance Loggable HI
instance Loggable HELLO
instance Loggable WORLD
main= keep $ do
flowAssign
proc <|> restore <|> save
where
proc= do
logged $ option "proc" "process"
r <- logged $ return HELLO
logged $ lprint r
setc
r <- logged $ return WORLD
logged $ lprint r
setc
r <- logged $ return HI
logged $ lprint r
save= do
option "save" "save execution state"
liftIO $ syncCache
restore= do
option "res" "restore"
s <- input (const True) "sesion >"
clos <- input (const True) "closure >"
noTrans $ restoreClosure s clos
lprint :: Show a => a -> TransIO ()
lprint= liftIO . print
setc = do
(lc,_) <- setCont 0
liftIO $ putStr "0 ">> print (localClos lc)Remote execution
- RPC: identical binaries in both nodes, call the remote routine by his physical address: This is the classical RPC mechanism, implemented initially in C and implemented in Cloud Haskell. The invoked routine should be at the top level.
- Send the code of the routine that will execute remotely, compile/interpret, invoke. Used in Unison. The invoked routine should be at the top leve (no scope).
- Send the entire stack of execution (closure) to the remote node. Used in Scheme and other LISP related languages where running code can be serialized. Has the advantage of calling routines within any scope, so the code is not a set of unrelated routines. The code continues in the remote node without breaking the flow (composability). Has the disadvantage of the huge size of the closures to be serialized and transported.
- Address the remote execution point by a path. Programs do not need to be identical, but to have the same structure. No need to transport code, can invoque routines within any scope. Invocation similar to a REST path, so it is lightweight. Instead of using absolute paths, a path from a known continuation point invoked previously can further reduce the data interchanged. Natural integration with HTTP-REST (almost for free). Since it composes all along the way and there are continuations, streaming is also natural
-
It is sad the lack of interoperability of Haskell libraries because there is no agreed standard monadic stack. The effect libraries have some nice characteristics: what effect is allowed, but they introduce complex types, are slow (now) and need more boilerplate to run the effects. His composability is as bad as other models.
Really, what a monadic stack need is pure and impure multistate for any data type, continuations and empty. That can be done within a Single and unique monadic stack. any number of readers and writers can be expressed in terms of state.
Exception code is another problem. It should be first class instead of a kind of side code. Exception monads imitate the model of native exceptions, that everyone try to avoid. By putting exception code in a stack that becomes an state of the computation, an exception can invoke in reverse order the list of exceptions that are set for his type. if the handler fails "repairing" the exception, the next exception handler can be invoked. If it succeed, the associated continuation can continue execution at that point. That way exception flow becomes first class, because it resumes in the main flow, and inherit all the execution stack.
Plutus
The essence of what I have done with plutus smart contract is to run them trough the IO monad:
main = do
print "hello, I'm the IO monad!"
initPAB simulatorHandlers
cid <- runPAB $ Simulator.activateContract (Wallet 1) GuessGame
runPAB $ waitNSlots 3
runPAB $ callEndpointOnInstance cid "lock" LockParams{secretWord="world", amount= Ada.adaValueOf 200}
runPAB $ waitNSlots 3
runPAB $ callEndpointOnInstance cid "guess" GuessParams{guessWord="world"}initPAB and runPAB are the primitives that I have developed to allow it.
In this program I invoke the guess game in which someone stores money and a key in a address of he blockchain identified with cid . If another send to the same address the correct key, he get the money.
The game smart contract is here
There are three things here:
- The smart contract, which run off-chain (the most part) and on-chain(basically, the redeeemer code).
- There is also the PAB and the simulator. The PAB (Plutus Application backend) is basically a giant dependency injection stuff which establishes the effects and everything that is available when something is evaluated in the smart contract.
- The third thing is the Simulator, which is the environment in this case, which the PAB bring to the smart contract. Other environment is the testnet which is a test blockchain and another is the real cardano blockchain.
The program produces this output:
Prelude Main> main
[INFO] Slot 0: TxnValidate b135806142f3d020fc68e9e72fa6e8e7c8fce34b2a0f17fd23b633641f58944a
[INFO] 9db4ce6e-479e-4fcf-977b-5d71c58d673c: "Waiting for guess or lock endpoint..."
[INFO] Initialising contract GuessGame with ID 9db4ce6e-479e-4fcf-977b-5d71c58d673c
[INFO] Activated instance 9db4ce6e-479e-4fcf-977b-5d71c58d673c on W1
[INFO] 9db4ce6e-479e-4fcf-977b-5d71c58d673c: "Pay Value (Map [(,Map [(\"\",200000000)])]) to the script"
[INFO] W1: Balancing an unbalanced transaction:
Tx:
Tx 29bd4df3f166bb1596ac1b7e57300d0fba664fde943b6ac45c682c366a482c0b:
{inputs:
collateral inputs:
outputs:
- Value (Map [(,Map [("",200000000)])]) addressed to
addressed to ScriptCredential: 96d9b249db40fe0b05dee4dfcecaafd3f18313e58f6054a7920608b8 (no staking credential)
mint: Value (Map [])
fee: Value (Map [])
mps:
signatures:
validity range: Interval {ivFrom = LowerBound NegInf True, ivTo = UpperBound PosInf True}
data:
"Hn\164b$\209\187O\182\128\243O|\154\217j\143$\236\136\190s\234\142Zle&\SO\156\184\167"}
Requires signatures:
Utxo index:
Validity range:
(-∞ , +∞)
[INFO] W1: Finished balancing. 6b0e3b04f7b5c00104564c3d9bf8633d85d38bdf2e2c8d66a5357c18160bf0e1
[INFO] W1: Submitting tx: 6b0e3b04f7b5c00104564c3d9bf8633d85d38bdf2e2c8d66a5357c18160bf0e1
[INFO] 9db4ce6e-479e-4fcf-977b-5d71c58d673c: "Waiting for guess or lock endpoint..."
[INFO] Slot 4: TxnValidate 6b0e3b04f7b5c00104564c3d9bf8633d85d38bdf2e2c8d66a5357c18160bf0e1
Nothing
[INFO] 9db4ce6e-479e-4fcf-977b-5d71c58d673c: "Waiting for script to have a UTxO of at least 1 lovelace"
[WARNINGPrelude Main> ] 9db4ce6e-479e-4fcf-977b-5d71c58d673c: "Correct secret word! Submitting the transaction"
[INFO] 9db4ce6e-479e-4fcf-977b-5d71c58d673c: "Submitting transaction to guess the secret word"
[INFO] W1: Balancing an unbalanced transaction:
Tx:
Tx bb08f5b021406223c4dab1fd3a99cd15fb191261a6a943bed747a96d8fe88000:
{inputs:
- 6b0e3b04f7b5c00104564c3d9bf8633d85d38bdf2e2c8d66a5357c18160bf0e1!1
"world"
collateral inputs:
outputs:
mint: Value (Map [])
fee: Value (Map [])