nicolashery

Nesting APIs and ReaderT environments in Haskell's Servant

Environments, from parent to child (or base to extended):

• App (ReaderT AppEnv IO):
  • HasLogFunc env
  • HasDatabase env
  • HasTracing env
• AppAuthenticated (ReaderT AppAuthenticatedEnv IO):
• HasApp env (everything from App)

nicolashery

Compare using a stack of transformers vs. the ReaderT pattern for a web service.

See files:

• Transformers.hs
• Reader.hs

jmatsushita

###
### [2023-06-19] UPDATE: Just tried to use my instructions again on a fresh install and it failed in a number of places. 
###.   Not sure if I'll update this gist (though I realise it seems to still have some traffic), but here's a list of 
###.   things to watch out for:
###      - Check out the `nix-darwin` instructions, as they have changed.
###      - There's a home manager gotcha https://github.com/nix-community/home-manager/issues/4026
###

# I found some good resources but they seem to do a bit too much (maybe from a time when there were more bugs).
# So here's a minimal Gist which worked for me as an install on a new M1 Pro.

natefaubion

module Main where

import Prelude

import Data.Symbol (class IsSymbol)
import Prim.Row as Row
import Prim.RowList as RowList
import Record as Record
import Type.Proxy

Willmo36

import { Comonad2C } from 'fp-ts/lib/Comonad';
import { pipe } from 'fp-ts/lib/function';
import { FunctionN } from 'fp-ts/lib/function';
import { Monoid } from 'fp-ts/lib/Monoid';
import { NonEmptyArray } from 'fp-ts/lib/NonEmptyArray';
import { pipeable } from 'fp-ts/lib/pipeable';

/**
 * OOP style builder pattern but in FP
 * References:

lexi-lambda

With scoped effects, handlers must be a part of the program

It is seductive to imagine that effect handlers in an algebraic effect system are not part of the program itself but metalanguage-level folds over the program tree. And in traditional free-like formulations, this is in fact the case. The Eff monad represents the program tree, which has only two cases:

data Eff effs a where
  Pure :: a -> Eff effs a
  Op :: Op effs a -> (a -> Eff effs b) -> Eff effs b

data Op effs a where

anka-213

coinSet = [1, 2, 5, 10, 20, 50, 100, 150, 200, 300]

-- When no coins are available, there is one way to get 0, no ways to get any other number
coins0 = 1:repeat 0

-- Given the result for previous coins, produce a list of possibilities for this coin type
coinsN coin preCoins = go 
  where 
    -- We can either get the value by using other coins or from an earlier value in this list

robrix

{-# LANGUAGE RankNTypes #-}
module Optics where

import           Control.Category ((>>>))
import qualified Control.Category as Cat
import           Control.Effect.Empty
import           Control.Effect.NonDet hiding (empty)
import           Control.Monad ((<=<))

-- riffing off of @serras’s post https://gist.github.com/serras/5152ec18ec5223b676cc67cac0e99b70

friedbrice

-- 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

serras

Some thoughts on building software

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