-
Go to
~/.stack/global-project/stack.yaml
and change theresolver:
section tolts-10.3
. -
Add:
- https://hackage.haskell.org/package/ghc-mod-5.9.0.0/candidate/ghc-mod-5.9.0.0.tar.gz
- cabal-helper-0.8.0.0
{-# LANGUAGE NoMonomorphismRestriction, FlexibleContexts, FlexibleInstances, DeriveFunctor #-} | |
import Data.Bool | |
import Data.Functor | |
import Data.Bifunctor | |
import Data.Function ((&)) | |
import Data.Semigroup | |
import Control.Applicative | |
import Control.Monad |
Derivations are the bread and butter of functional programming. It is easy to fall into the trap of thinking it is a pointless academic exercise, which is the reason why a lot of people struggle with FP. Functional programs are not so much written, they're calculated. It is here that the true power of equational reasoning (i.e. being able to swap the left and right parts of an equation everywhere in the code) help us.
So, getting comfortable reading and doing derivations is a must for any FP practitioner.
Below are the ones we did in the previous sessions, plus a couple of exercises.
(previous Yoneda blog) (reddit) (twitter)
Let's explore the Yoneda lemma. You don't need to be an advanced Haskeller to understand this. In fact I claim you will understand the first section fine if you're comfortable with map
/fmap
and id
.
I am not out to motivate it, but we will explore Yoneda at the level of terms and at the level of types.
{-@ LIQUID "--no-totality" @-} | |
{-@ LIQUID "--no-termination" @-} | |
{-# LANGUAGE InstanceSigs #-} | |
{-# LANGUAGE LambdaCase #-} | |
{-# LANGUAGE FlexibleInstances #-} | |
{-# LANGUAGE MultiParamTypeClasses #-} | |
{-# LANGUAGE FlexibleContexts #-} | |
{-# LANGUAGE ConstraintKinds #-} | |
{-# LANGUAGE UndecidableInstances #-} | |
{-# LANGUAGE TypeFamilies #-} |
Lately I have been busy reading some new books on Domain Driven Design (DDD) and software architecture -- including a short yet eye-opening one in Python and a great one in F#. At the same time, it seems that more people in the Functional Programming world are looking at more formal approaches to modelling -- some examples here. This has brought some thought from the background of my brain about how we should model, organize, and architect software using the lessons we've learnt from functional programming.
Before moving on, let me be clear about this being just a dump of some thoughts, not always well-defined, definite
-- ghcid -c'stack repl --resolver nightly --package time' haskell-time.hs --allow-eval | |
---- | |
-- # Haskell Time Crib Sheet | |
---- | |
-- Excellent sources for this small guide include: | |
-- | |
-- * https://two-wrongs.com/haskell-time-library-tutorial.html | |
-- * https://williamyaoh.com/posts/2019-09-16-time-cheatsheet.html |
import scala.compiletime.ops._ | |
import scala.compiletime.ops.int._ | |
import scala.compiletime.ops.any._ | |
/** | |
* Type your matrices for great good: a Haskell library of typed matrices and applications (functional pearl) | |
* https://dl.acm.org/doi/10.1145/3406088.3409019 | |
*/ | |
object Test { |
Twitter threads from @smdiehl on Crypto Skepticism