The following are appendices from Optics By Example, a comprehensive guide to optics from beginner to advanced! If you like the content below, there's plenty more where that came from; pick up the book!
import Data.Monoid | |
-- This code doesn't work... | |
-- How can you make a multi-parameter data type be Foldable? | |
-- foldMap over `a` so it can be converted to a Monoid | |
data BinaryTree3 a v | |
= Node3 a (BinaryTree3 a v) (BinaryTree3 a v) | |
| Leaf3 a v | |
deriving (Show) |
Our web applications are getting increasingly more complicated. They are becoming more distributed and increasingly powered by combinations of complex, constantly changing and large datasets. All while users are increasingly more connected and want the latest information instantly without any slow page loads or stale information.
To address this, developers have turned to layers of caching and single page applications so that there are layers of aggregated and preloaded state as close to the user as possible, to be immediately available when it is requested. This comes at a high cost: it is very difficult to invalidate or update those caches when the upstream information changes. This is especially problematic when the stale caches can accidentally cause real bugs rather than show stale data to users.
The big issue here is that we're not just caching expensive-to-compute static data. We are caching data that changes over time. There are a number of architectual patterns that can be applied, but to date, n
hardCoreFunction a b c = | |
let z = a + b | |
k = b + c | |
in | |
error "todo" z + k -- this obviously type-checks |
object blah { | |
case class OptionT[F[_], A](x: F[Option[A]]) | |
trait Functor[F[_]] | |
object Functor { | |
implicit val OptionFunctor: Functor[Option] = | |
sys.error("todo") | |
} | |
object OptionT { | |
implicit def OptionTFunctor[F[_]: Functor]: Functor[({ type l[a] = OptionT[F, a] })#l] = |
#include <tr1/type_traits> | |
#include <iostream> | |
#include <vector> | |
#include <algorithm> | |
// (* -> *) -> Constraint | |
template<template <typename> class T> | |
class Functor { | |
public: | |
template <typename A, typename B> |
import Control.Applicative | |
import Control.Concurrent (forkIO, newEmptyMVar, putMVar, takeMVar) | |
import Control.Monad | |
import Control.Monad.Trans.Class | |
import Control.Monad.IO.Class | |
import System.Command | |
newtype Cmd m a = Cmd { runCmd :: m (Either (Int, String) a) } | |
cmd :: MonadIO m => FilePath -> [String] -> String -> Cmd m String |
There seems to be a lot of confusion around Effects and IO. I wanted to collect a set of questions and answers, and explanations of common misconceptions.
- What is an Effect?
Effects come in many different shapes. In terms of monadic effects, there are different shapes again. For example, List (non-determinism), State, IO, Cont.
- What is a Side Effect?
An effect that is occurs to the side of the effect you are otherwise running within. In most standard environments, this is an IO effect that occurs outside of the otherwise effectful environment.
name: package | |
version: 0.0.1 | |
license: BSD3 | |
license-File: LICENCE | |
category: Development | |
cabal-version: >= 1.10 | |
build-type: Custom | |
flag small_base | |
description: Choose the new, split-up base package. |
// see https://github.com/gseitz/Lensed | |
case class CoState[A, B](put: A => B, pos: A) | |
object CoState { | |
type Store[A, B] = CoState[A, B] | |
} | |
// fused get/set | |
case class Lens[A, B](lens: A => CoState[B, A]) { |