This article describes a technique for joining (in an SQL-style) lists of haskell data structures.
Maybe not the fastest, maybe not the smartest, but it works.
| -- Worth reading http://www.geeksforgeeks.org/convex-hull-set-2-graham-scan/ | |
| import Text.Printf | |
| import Data.List | |
| type Point = (Double, Double) | |
| -- Euclidean distance | |
| dist :: (Double, Double) -> (Double, Double) -> Double | |
| dist (x1, y1) (x2, y2) = sqrt (f x1 x2 + f y1 y2) |
| {-# LANGUAGE OverloadedStrings #-} | |
| {-# OPTIONS_GHC -Wall #-} | |
| -- Set your font to a monospace font which makes this character the same as the line-height: │ | |
| -- | |
| -- Otherwise, you'll see an ugly gap between connected lines if the | |
| -- line-height of the font is high. | |
| -- | |
| -- Example fonts: | |
| -- |
| --Roughly based on https://github.com/Gabriel439/Haskell-Morte-Library/blob/master/src/Morte/Core.hs by Gabriel Gonzalez et al. | |
| data Expr = Star | Box | Var Int | Lam Int Expr Expr | Pi Int Expr Expr | App Expr Expr deriving (Show, Eq) | |
| subst v e (Var v') | v == v' = e | |
| subst v e (Lam v' ta b ) | v == v' = Lam v' (subst v e ta) b | |
| subst v e (Lam v' ta b ) = Lam v' (subst v e ta) (subst v e b ) | |
| subst v e (Pi v' ta tb) | v == v' = Pi v' (subst v e ta) tb | |
| subst v e (Pi v' ta tb) = Pi v' (subst v e ta) (subst v e tb) | |
| subst v e (App f a ) = App (subst v e f ) (subst v e a ) |
| module ServantAuthGoogle where | |
| import ClassyPrelude hiding (Handler) | |
| import Control.Error.Util (hush) | |
| import Control.Lens ((.~), (^.), (^?)) | |
| import Control.Monad.Except | |
| import qualified Crypto.JOSE as Jose | |
| import qualified Crypto.JWT as Jose | |
| import Crypto.Util (constTimeEq) | |
| import Data.Aeson |
| module SimpleDep | |
| basic : (b : Bool) -> if b then String else Int | |
| basic True = "it's true" | |
| basic False = 0 | |
| ------------- | |
| data WhatIsIt = AString | AInt |
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
My initial motivation for -XDerivingVia was deriving across
isomorphisms.
Standard type-class encodings of isos turn out to be awkward due to overlap.
| {-# language TypeInType, GADTs, TemplateHaskell, ExistentialQuantification, | |
| TypeApplications, TypeFamilies, TypeOperators, StandaloneDeriving, FlexibleContexts, | |
| RankNTypes #-} | |
| import Data.Kind | |
| import Data.Singletons | |
| import Data.Singletons.TH | |
| data Sigma a f = forall (x :: a). Sigma (Sing x) (Apply f x) |
| -- http://comonad.com/reader/2018/the-state-comonad/ | |
| -- https://www.reddit.com/r/haskell/comments/7oav51/i_made_a_monad_that_i_havent_seen_before_and_i/ | |
| {-# language DeriveFunctor #-} | |
| import Control.Comonad | |
| import Data.Semigroup | |
| data Store s a = Store { peek :: s -> a, pos :: s } deriving Functor |