anka-213

{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FlexibleContexts #-}

module CheckStrictness where
import GHC.Generics

ekmett

#!/usr/bin/env cabal
{- cabal:
build-depends: base, constraints, ghc-prim
-}
{-# language AllowAmbiguousTypes, ConstrainedClassMethods, ConstraintKinds,
             DefaultSignatures, FlexibleInstances, ImplicitParams, RankNTypes,
             ScopedTypeVariables, TypeApplications, TypeFamilies, UndecidableSuperClasses #-}

import Control.Applicative
import Control.Concurrent.MVar

quelgar

Every Argument for Static Typing Applies to Typed Errors

Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.

An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.

Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty

gcanti

// Adapted from http://code.slipthrough.net/2016/08/10/approximating-gadts-in-purescript/

import { Kind, URIS } from 'fp-ts/lib/HKT'
import { URI } from 'fp-ts/lib/Identity'
import { identity } from 'fp-ts/lib/function'

// ------------------------------------------
// Leibniz
// ------------------------------------------

paf31

{-# language FlexibleContexts #-}
{-# language TypeOperators #-}

module DKT where
  
import Control.Monad (guard)
import Control.Monad.Error.Class (throwError)
import Control.Monad.Trans (lift)
import Control.Monad.Trans.State
import Control.Monad.Trans.Writer

lexi-lambda

Monads and delimited control are very closely related, so it isn’t too hard to understand them in terms of one another. From a monadic point of view, the big idea is that if you have the computation m >>= f, then f is m’s continuation. It’s the function that is called with m’s result to continue execution after m returns.

If you have a long chain of binds, the continuation is just the composition of all of them. So, for example, if you have

m >>= f >>= g >>= h

then the continuation of m is f >=> g >=> h. Likewise, the continuation of m >>= f is g >=> h.

wokalski

BuckleScript friendly vim + official ocaml-lsp setup for Reason/OCaml

Prerequisite: Install esy 0.6.0.

Steps

1. Check esy version (it has to be >0.6.0)
2. Create esy.json with the following contents next to package.json:

ChrisPenner

Optics By Example Cheat Sheets

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!

• Operators
• Composition Guide
• Substitution Guide
• Optical Constarints and Types

Operator Cheat Sheet

runarorama

Pos.doc = [: Represents a position in memory :]

unique type Pos = Pos Nat
-- Lets us refer to the Pos pattern unqualified
use Pos Pos


Error.doc = [: This ability lets us fail with an error anywhere. :]

ability Error where

fumieval

{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeApplications #-}
module Data.Aeson.Extras where

import Data.Aeson