No Such Blog or Diary

幹事は根性入れてやってはいけない．本業が忙しいのに余計なことして全部中途半端はいけない．手を抜こう，そうしよう．

歌舞伎か能楽か……　つーか，チケットの手配のタイミングが合わないぜよ．

既存の技術を使わず無理やりアドホックに関数を作り型を合わせた．

というか，本来型の異なる相互再帰な関数なのにそれを無理やり一本化しているからおかしいのよね……　相互再帰関数って戻り値の型さえ合っていればただの再帰関数か．

さて，週末に片づけると言っておいた部分を朝が来る前に片づけよう．

とある関数に型が付かなった．入力の構造に応じて戻り値の型が違う．誰だこんな関数を定義したのは．

おかげで仕事も片付かない．

気づけば日が昇って降り始めている……

とりあえず，k 分木に対して節点の親子の対称性を良くした k+1 分木を考えて，その上で構成子間に結合性を導入すれば木の 3rd hom と同じになると．条件付きの構成子のほうが扱いやすいのでこっちでいこう．

寝る．

ここんとこ暑くなったせいか事務方からの「節電の徹底のお願い」が３日連続で出されている．一昨日は昼前で，ここ２日は午後３時ごろ．暑くて皆が冷房を使うようになったせいかね．ぶっちゃけ外の日蔭にいたほうが風があって涼しいのだけど，残念ながら講義とかはこの暑い時間帯に部屋の中でなのよね．

１日で一番涼しい明け方を中心に生活すれば省電力になるだろうか？　そして一番暑い午後は昼寝で過ごすとか．

閑話休題．

暑くてたまらないので小さめの縦型スリムファンを導入．これで室温３０度越えでも生活できる．

同じ式の中に出てきている同じ名前の関数が全く別物であるという点でプログラムが読めない．型を追いかけて行かないと何が起きているのか分からないし，そもそも型推論しないと読めないプログラムって何なのよ……

でだ，typeclass に対して polymorphic な式の評価とか訳が分からなくなってくる．その式につける型アノテーションを変えると全く別の結果が出てくるとか……

で，悩んだ末にようやく悟りが開けた．typeclassの型を指定するってのは式に代入する関数集達を一気に指定するってことなのね．普通は高階関数なアルゴリズムに代入すべき関数を引数として渡すのだけど，typeclass を使った場合には型を介して暗黙にアルゴリズムに関数を引き渡していると．

うーん，これって良いことなのか悪いことなのかいまひとつわからない．特定の性質を満たしているであろう関数達というのを型で静的に確かめておけるのは良いのだけど，一方でわざわざインスタンス宣言しなきゃならないしコードは一見簡潔だけど意味を読み取りにくいし．

とりあえず，アルゴリズムをプログラムする人間の書くコード量が減るという点は理解した．