Write DApps as continuous workflows
Progress Report January 2023
Uniswap example problem unsolved
commits of code this month
#!/usr/bin/env execthirdlinedocker.sh | |
-- mkdir -p ./static && ghcjs -DDEBUG ${1} -o static/out && echo ${1} && runghc -DDEBUG ${1} ${2} ${3} | |
{- | |
Programmed following the requirements of a canonical Java project: | |
http://www.math-cs.gordon.edu/courses/cs211/ATMExample/ | |
It demonstates that it is possible to program clearly at the level of the requirements so that the author of the requirements |
{-# LANGUAGE MultiParamTypeClasses, ExistentialQuantification, ScopedTypeVariables, FlexibleInstances, FlexibleContexts, UndecidableInstances #-} | |
module TransientCont where | |
-- some imports | |
import Control.Applicative | |
import Control.Monad.IO.Class | |
import Control.Monad.Trans |
Write DApps as continuous workflows
Progress Report January 2023
Uniswap example problem unsolved
commits of code this month
Write DApps as continuous workflows
Progress Report December 2022
Uniswap example problem unsolved
Commits on Dec 27, 2022
This is a serie of reflections on the presentation of Runar Branson Specifically, in the 39:30 he mention side effects as one of the main causes of the lack of composability. Most of the time we need the effects arranged in a different way than the one that forces the composition. For the example that he mentions: choose coffe, pay, serve, we can sustitute the one whose effect we want to reorder (pay) by one non-effectful, (add-to-cart) so that we can make many selections and pay at the end. What we do is to keep in the cart state the items selected.
But there are other reasons why side effects can prevent composition: threading, blocking for wathever reasons: communications, semaphores, callbacks, concurrency, loops waiting for some conditions... These are considered as lost cases for composition and not even mentioned. But transient demonstrates that this is not the case, that it is possible t
This is a tutorial about how to handle the complete state of a computation so that it can be serialized, stored, translated, analyzed, restored his execution etc
This text summarizes my reseach with Transient in this aspect which is the least known. I want to make it public since I belive has useful contributions to real world computing problems in novel ways and may make a difference. The text is the result of a balance between didactic simplicity (my intention) and the terseness of my laziness.
I use a pseudocode similar to Haskell. This is a very first version which will have errors for sure. But it gives an idea. I will perfect the content from time to time to make it more informative. At first it will be a gist.
forM [1..10] $ \i -> ... use: i <- threads 0 $ choose [1..10]
-- run in the current thread
-- like for i = 1 to 10...
react
:onCallback wathever mycallback use: event <- react (onCallback wathever) (return())
import Transient.Base | |
import Network | |
import System.IO | |
import Control.Monad.IO.Class | |
import Control.Applicative | |
-- taken from Pipes example | |
-- https://www.reddit.com/r/haskell/comments/2jvc78/simple_haskell_irc_client_in_two_lines_of_code/?st=iqj5yxg1&sh=0cb8cc11 | |
-- Simple Haskell IRC client in "two lines of code" |
I was looking at the last article of Michael Snoyman about asynchronous exceptions. Proper handling of resources in long term programs such are servers demands very accurate management of resources. In transient where many threads are spawned and sometimes killed asynchronously, this is even more important.
So I first tried to create a version of bracket
for the transient monad:
bracket