おもち
class Foo a where
f :: (a -> a) -> a -> a
というクラスと
class Bar a where
g :: (forall b . b -> b) -> a -> a
とだと、「関数gのほうが引数に強い条件をつけている」ことから「クラスBarのほうがインスタンスにゆるい条件しか要求しない」ということになる。
class Bar a where
...
default g :: Foo a => (forall b . b -> b) -> a -> a
g = f
とはできるけど、逆はできないので確かめられる。
けど、なんか、まぎらわしいな。
データ構造が空でないことを表現するのにnot emptyとかではなくて肯定的に表現することってできないかな。
isEmpty [] = True
isEmpty _ = False
だとなんか思考に負荷がかかる。
「型パズルは解けたけど動きませんでした」という場合のわりとあるパターンとしては、条件の厳しい型クラスを作ることで、型チェックは通るのだてど、その型クラスのインスタンスにできるようなまともな型が作れないみたいな話。
かなり、相当に悩んでいた型パズルがなんか意外に簡単に解けてしまったために、逆に不安になっている。
「型パズルは解けたけど動きませんでした」ってことはまあまあ、あるにはある。うまく動くといいけど、もうすこし形を整えてから動かしてみようかと。
Get type and kind 1人では解けない型のパズルを抱いて
真と偽を並べるときに、真 -> 偽の順に並べる場合が多いのかなとは思うのだけど、プログラミングでは偽を0とし真を1とする関係で、偽 -> 真の順に並べたい気持ちが強いかもしれない。
bool :: a -> a -> Bool -> a
maybe :: b -> (a -> b) -> Maybe a -> b
either :: (a -> c) -> (b -> c) -> Either a b -> c
ってのがあるんだから、
list :: b -> (a -> [a] -> b) -> [a] -> b
があってもいいと思うんだけど。
コードで1行何文字までとするかという話だけど、あまり横に長くするのは好きじゃないので、80文字までにしてる。あとタブはハードタブで8文字分にしてる。
入れ子が深くなると左によりすぎるのだけど、それは関数や変数をくくり出すサインだと思ってる。
で、コードがんがん書いてますよってときは横に長くなってもいいことにしていて、リファクタリングで80文字におさまるようにするってのが、わりといい感じの運用になってる。
MonadPlusかつTraversableなデータ構造ってどんなのがあるだろう。
このあたり、何でもかんでも盛りだと、「ほぼリスト」になりがちな気がする。
場合によってはApplicativeではなくMonadであることを利用して効率的な定義ができるかもしれないということだろうか。
TraversableクラスのメソッドにtraverseとmapMの両方がある意味って何だろう。
Haskellで「基本的なモナド」を独断で選ぶなら、
Except, Fail, IO, NonDet, Reader, ST, State, Writer
ってとこかな。NonDetはListモナドを含む感じで。
さらにこの基本的なモナドを分類すると
状態系: Reader, Writer, State
分岐系: Except, Fail, NonDet
副作用系: ST, IO
となるかな。
Yaftee
Yet Another "heFTy algebras"-inspired Extensible Effects
importをimoprtにタイポするなど