name は env に依存してないってだけなのに、それだけで、`AnyBot`の定義のせいで異質なメソッドになっちゃってる感じですね༼;´༎ຶ ༎ຶ༽envが多相的なのは Has Type Class Pattern とかいうしきたりを真似してみたかんじです:sob:QuantifiedConstraintsなんて拡張があるんですね！AnyBot :: forall b. (Bot b, forall env. Dep AnyBot env => BotDep b env) => b -> AnyBot
AnyBot の型パラメタに env をもたせると、`env` を必要としない name メソッドの呼び出しがえらいことになるから、`AnyBot` に env をもたせない。reply メソッドの呼び出しに必要な Dep b env が足りなくなっちゃうから、`AnyBot` にパターンマッチしたときに使える制約に forall env. Dep b env 的なものを入れたい。QuantifiedConstraints 拡張では Dep b env みたいな型族をかけないから、仕方なく BotDep 型クラスを追加して、`instance Dep AnyBot env => BotDep AnyBot env` とかやって BotDep から Dep が得られるようにしてる。BotDep 型クラスについてですが、これは本質的なものではなくて QuantifiedConstraints の制約でこういうのを作らないといけないというだけですね。forall env. Dep AnyBot env => ... の ... の部分には type family は書けません。なので、`forall env. Dep AnyBot env => Dep b env` とは書けないので、代わりに Dep b env に相当する型クラス BotDep b env を作ってそれを指定しています。forall env. Dep AnyBot env => BotDep b env ってのは、左辺の Dep AnyBot env の制約が右辺の BotDep b env より厳しい、即ち、`type Dep AnyBot env = ...` で羅列されてる制約の中に、packされようとしている Bot インスタンスの Dep の制約が含まれてることを要求してるんですね!BotDep 型クラスのあたりもいまいちどういう発想て゛そんなこと考えついたのかわかりません:sob:go :: Bot b => BotDep b env => b -> String -> RIO env (Maybe String) の部分の => が重なっているのはなぜなのでしょうか?go :: Bot b => BotDep b env => b -> String -> RIO env (Maybe String) の部分の => が重なっているのはなぜなのでしょうああ、すいません。癖で書いちゃいましたが、`Bot b => BotDep b env =>` は
(Bot b, BotDep b env) => と同じですAnyBot を constraint 持てるようにしておくと，後から変えられて確かに便利ですね．HList のところは，単に一々 SomeBot を allBots の全てのボットで書くのが面倒という理由で使ってるなら，ビルダをそもそも定義すればいいだけだと思いますね．その例が上に post したやつです(Bot a, Bot b) => Bot (a, b) を作ってみるのはどうでしょう？型クラスはこのような一般性のあるインスタンスにおいて力を発揮します(nameがリストを返すようにするなどの変更は必要かもしれませんが)cabal new-install pandoc
cabal list --installed
~/.ghc, ~/.stack等）や，Homebrew等で入れたHaskell関連のパッケージはいったん全部削除してから作業しています．$ ghcup --version The GHCup Haskell installer, version v0.1.12 $ cabal --version cabal-install version 3.2.0.0 compiled using version 3.2.0.0 of the Cabal library
cabal list --installed が正しくnix-style local build（いわゆる new-install インストールしたりするやつですね）でインストールしたパッケージを正しく認識していないのが原因なんだと思われます。pandoc コマンドは多分に問題なく使えるでしょうし、 pandoc に依存したプロジェクトを作る場合でもcabalファイルに pandoc を書けば問題なく使えるはずです（必要なバージョンがインストールされてない場合はビルド時に再度インストールされるだけ）。cabal list --installed が修正されていないのではないかと推測しています。cabal new-install --lib pandoc であればもしかしたら結果が変わるかも知れません。どちらにしても問題なく使えるとはは思いますが~/.cabal 以下にインストールされたものはちゃんと使えるのですが，何となく変な感じですよね．cabal new-exec （もしかしたら最近のcabalだともう new- は要らないかも）を使って、 cabal new-exec ghc-pkg list はいかがでしょうか？自分がインストール済みのパッケージの一覧をとるときは大抵 ghc-pkg list を使いますね。（ぶっちゃけ cabal list コマンド自体初めて見たかもしれない... :sweat_smile: ）compiler/GHC/Driver/Pipeline.hs 付近のコードになります。(HogeBot,(FugaBot,PiyoBot))とかすればリストみたいにできちゃいますね〜ふむふむ…allBots = MarkovChain :+: Shiritori :+: HNil
allBots :: HList HasLogFunc
type family (:&&:) c1 c2 :: Type -> Constraint where (:&&:) c1 CEmpty = c1 (:&&:) CEmpty c2 = c2 (:&&:) c c = c (:&&:) c1 c2 = c1 :&: c2 data HList :: (Type -> Constraint) -> Type where HNil :: HList CEmpty (:+:) :: (Bot b) => b -> HList c -> HList (Dep b :&&: c)
go :: Bot b => BotDep b env => b -> String -> RIO env (Maybe String)
Dep b env じゃ動かないんでしょうか?MIN_VERSION_conduit でひっかかるのですが、理由が分かる人はいませんか？data Foo = Foo {-# UNPACK #-} !Int {-# UNPACK #-} !Int
data Bar = Bar {-# UNPACK #-} !Int !Foodata Foo = Foo {-# UNPACK #-} !Int {-# UNPACK #-} !Int
data Bar = Bar {-# UNPACK #-} !Int {-# UNPACK #-} !Foo