Find it here: https://github.com/bitemyapp/learnhaskell
Fire up ghci. Make the text real big. Always show the types for everything as you go!
Takes ~1 hour generally.
Note: if you object to "uncertainty" (evocative of data/value flow possibilities), consider wording like "simultaneously possible values". It's a reference to how the compiler won't know whether Maybe a
is a Just a
or a Nothing
statically. Don't blather at me about dependent types; I know.
Alternate verbiage for uncertainty: product - simultaneous altogetherness, sum - simultaneous singlehood. Also consider what the category theoretic diagrams look like. Can be instructive.
Suggestions taken under advisement.
From: sanguineempiricist@hushmail.com
Subject: We get it. You learned Haskell and Type theory. Cute.
Nobody gives a shit if any one can do math "in their head". What an outdated fucking analogy.
A) No one considers them good
B) The fact that your post lends so much emphasis to the "doing it all in your head" shows that you are lost in your little world of slight delusion.
This is a quick run-through of how I connected to Redis from a Yesod site (which used the default scaffolding). There isn't much specific to Redis here, so this information should apply to connecting to any database or service from Yesod.
First, a brief intro of the basics of Hedis:
{-# LANGUAGE OverloadedStrings #-}
The question of "How do I design my application in Haskell?" comes up a lot. There's a bunch of perspectives and choices, so it makes sense that it's difficult to choose just one. Do I use plain monad transformers, mtl
, just pass the parameters manually and use IO
for everything, the ReaderT
design pattern, free monads, freer monads, some other kind of algebraic effect system?!
The answer is: why not both/all?
Lately, I've been centering on a n application design architecture with roughly three layers:
newtype AppT m a = AppT { unAppT :: ReaderT YourStuff m a } deriving ............
The ReaderT
Design Pattern, essentially. This is what everything gets boiled down to, and what everything eventually gets interpreted in. This type is the backbone of your app. For some components, you carry around some info/state (consider [MonadMetrics
](https://hackage
For a brief user-level introduction to CMake, watch C++ Weekly, Episode 78, Intro to CMake by Jason Turner. LLVM’s CMake Primer provides a good high-level introduction to the CMake syntax. Go read it now.
After that, watch Mathieu Ropert’s CppCon 2017 talk Using Modern CMake Patterns to Enforce a Good Modular Design (slides). It provides a thorough explanation of what modern CMake is and why it is so much better than “old school” CMake. The modular design ideas in this talk are based on the book [Large-Scale C++ Software Design](https://www.amazon.de/Large-Scale-Soft
# Install a local copy of Hoogle (OS X, HP) | |
# Download | |
cd | |
cabal unpack hoogle | |
cd hoogle-4.2.26/ | |
# Build | |
cabal sandbox init | |
cabal install -j --dependencies-only |
I hereby claim:
- I am bitemyapp on github.
- I am bitemyapp (https://keybase.io/bitemyapp) on keybase.
- I have a public key whose fingerprint is 81D6 75D8 29F1 8485 FDBD B4E2 5809 8478 C9E4 05E5
To claim this, I am signing this object:
{-# language TypeInType, QuantifiedConstraints, ConstraintKinds, RankNTypes, UndecidableInstances, MultiParamTypeClasses, TypeFamilies, KindSignatures #-} | |
module QC where | |
import Data.Constraint | |
import Data.Functor.Contravariant | |
import Data.Kind | |
import Data.Profunctor | |
type C = (Type -> Type) -> (Type -> Type -> Type) -> Constraint |