HaskellでApplication Architectureを作るときのパターン

ReaderTパターンのボイラープレート多すぎ問題をDerivingViaを使って解決する

Library

関連

なにをパターンと呼んでいるのか

Libraryとの関係性がわかっていない

そのLibraryがなくても実現可能なものなのか

Extensible Effectsと関係ある？

これもモナド変換子を代替するやつだと思うけど

IOHKの記事内の文脈の capbility と同じ意味？

参考

本家

ReaderTパターンやThree Haskell Cakeの話が前提にある

そもそもHaskell CakeがReaderTの拡張っぽいものなので、

気になるのは #??

capabilityパターンとhaskell cakeの違い

halogen realworldは結局どっちなのか

なんか読みづらいな..

最初の見出しの「THE DIFFERENCE WITH THE MTL」は、

mtlとReaderTパターンの差異を述べている

とりわけmtlの問題点を述べている

ReaderTパターンは、モナドを積み立てなくても、個別の関数を実行できる

それ故に、この個別のモナドのことをcapabilityと呼ぶ

次の見出しの「THE PROBLEM」は、mtlの問題を述べている

mtlはモナドのレイヤーがあるせいで(?)、同じ型の2つの状態を持てない #??

よくわからんが、何かしら強すぎる制限がある

when we give a concrete monad stack, then all the instances are automatically computed for us

全てのinstanceが計算される(されてしまう？)

具体的にどういうことを言っているのかはわからん #??

一方でReaderTパターンはAppMに全てのcapablilityを収集する

ただし、ReaderTパターンの欠点としてボイラープレートが多すぎるというのがある

ReaderTの記事ではLensで解決する、というのも書いてるがあまり触れられていない

DerivingViaを使ってそのボイラープレート問題を解決する

DerivingVia知らないと理解できなさそう

いったん保留