(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs
This is material to go along with a 2014 Boston Haskell talk.
We are going to look at a series of type signatures in Haskell and explore how parametricity (or lack thereof) lets us constrain what a function is allowed to do.
Let's start with a decidedly non-generic function signature. What are the possible implementations of this function which typecheck?
wrangle :: Int -> Int
The indexed state monad is not the only indexed monad out there; it's not even the only useful one. In this tutorial, we will explore another indexed monad, this time one that encapsulates the full power of delimited continuations: the indexed continuation monad.
The relationship between the indexed and regular state monads holds true as well for the indexed and regular continuation monads, but while the indexed state monad allows us to keep a state while changing its type in a type-safe way, the indexed continuation monad allows us to manipulate delimited continuations while the return type of the continuation block changes arbitrarily. This, unlike the regular continuation monad, allows us the full power of delimited continuations in a dynamic language like Scheme while still remaining completely statically typed.
module type Functor = sig | |
type 'a t | |
val map : ('a -> 'b) -> 'a t -> 'b t | |
end | |
module type Monad = sig | |
type 'a t | |
val map : ('a -> 'b) -> 'a t -> 'b t | |
val return : 'a -> 'a t |
Every application ever written can be viewed as some sort of transformation on data. Data can come from different sources, such as a network or a file or user input or the Large Hadron Collider. It can come from many sources all at once to be merged and aggregated in interesting ways, and it can be produced into many different output sinks, such as a network or files or graphical user interfaces. You might produce your output all at once, as a big data dump at the end of the world (right before your program shuts down), or you might produce it more incrementally. Every application fits into this model.
The scalaz-stream project is an attempt to make it easy to construct, test and scale programs that fit within this model (which is to say, everything). It does this by providing an abstraction around a "stream" of data, which is really just this notion of some number of data being sequentially pulled out of some unspecified data source. On top of this abstraction, sca
At DICOM Grid, we recently made the decision to use Haskell for some of our newer projects, mostly small, independent web services. This isn't the first time I've had the opportunity to use Haskell at work - I had previously used Haskell to write tools to automate some processes like generation of documentation for TypeScript code - but this is the first time we will be deploying Haskell code into production.
Over the past few months, I have been working on two Haskell services:
I will write here mostly about the first project, since it is a self-contained project which provides a good example of the power of Haskell. Moreover, the proces
-- See http://blog.ezyang.com/2012/08/applicative-functors/ | |
module Main | |
where | |
import Prelude hiding ((**)) | |
import Control.Monad | |
bind :: Monad m => m a -> (a -> m b) -> m b | |
bind = (>>=) |
// Run this with scala <filename> | |
/** | |
* A Two-phase commit Monad | |
*/ | |
trait Transaction[+T] { | |
def map[U](fn: T => U): Transaction[U] = flatMap { t => Constant(fn(t)) } | |
def flatMap[U](fn: T => Transaction[U]): Transaction[U] = | |
FlatMapped(this, fn) |
We've already looked at two different indexed monads in our tour so far, so let's go for a third whose regular counterpart isn't as well known: the privilege monad.
The regular privilege monad allows you to express constraints on which operations a given component is allowed to perform. This lets the developers of seperate interacting components be statically assured that other components can't access their private state, and it gives you a compile-time guarantee that any code that doesn't have appropriate permissions cannot do things that would require those permissions. Unfortunately, you cannot easily, and sometimes cannot at all, build code in the privilege monad that gains or loses permissions as the code runs; in other words, you cannot (in general) raise or lower your own privilege level, not even when it really should be a