ttaakkee
env
が多相的なのは Has Type Class Pattern とかいうしきたりを真似してみたかんじです:sob:メソッドの呼び出し元によって具体的な`env`の型が変わり得るので多相的にしたい感じです:sob:
整理して考えるとたしかに!name
は env
に依存してないってだけなのに、それだけで、`AnyBot`の定義のせいで異質なメソッドになっちゃってる感じですね༼;´༎ຶ ༎ຶ༽
(ちなみにpackってなんですか?:exploding_head:)
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 !Foo
data Foo = Foo {-# UNPACK #-} !Int {-# UNPACK #-} !Int data Bar = Bar {-# UNPACK #-} !Int {-# UNPACK #-} !Foo