2009-10-24
■ [ruby] gem-depcleanについて、とりとめもないこと
RubyGemsをgentooのPortage風に管理するプラグイン、gem-depcleanをid:ursmさんが公開されています。
やりたいことは
- 依存元がなくなったgemの削除
- 必要なgem・versionだけ残すgem clean
の2つですよね。
前者について
これはRubyGemsの機能として含まれるべきでしょう。uninstallの時に、「それが必要としているが、他から必要とされていないgem」を 同時に消すオプションがあれば良いんですよね。
後者について
「gem clean railsしたら、昔書いたアプリで使ってたバージョンが消えて困った」とかの経験は僕もあります。
「このバージョンはまだ使ってます」フラグを立てることが出来たら良いのかも。(aptitudeのピンがそういうもんなのかな)
RubyGemsに手を入れない解としては、依存があればcleanされないわけだから、人工的に依存を作り出すというアプローチもありますね。 空のgemを作って、それがrails 2.1.1とかに依存していることにしておく。
例：
このpin_gem.gemspecを適当に書き換えて、gem build pin_gem.gemspec → gem install pin_gem-0.0.1.gem とする。
■ [haskell][memo] Functor, Monoid, Monad, Arrowなどについて解説した「Typeclassopedia」
注) 激しく上級者向けです。
半分くらいしか理解できた気がしないけど、面白かったです。GHCのライブラリのソースを見てて、FunctorとかMonoidとかなんなの！と思ってたので。
結局、「Rubyがeach＋Enumerableで行っているようなことを、Haskellはもっと大規模に行っているのだ」という解釈をしました。
RubyのEnumerable
Rubyでは「eachメソッドを定義したクラス」にEnumerableモジュールをインクルードすることで、 eachを使って実装されたさまざまなメソッドが使えるようになります。 EnumerableをインクルードしているクラスはArray, Hash, Rangeなどたくさんありますが、 eachが定義できる、即ち「要素を列挙可能である」という性質がこれらに共通していると考えることができます。
Haskellでは？
「Enumerable(each)：要素を列挙できるやつ」だとすると、
- Functor(fmap): 中になんか入ってるやつ。リストとかいろいろ
- Monoid(mempty, mappend): 「ゼロ」と「プラス」を持つやつ
- Foldable(fold/foldMap): 畳み込みできるやつ*3
- Traversable(traverse/sequenceA): 畳み込むんじゃなくて、構造を維持したまま、ええと…
- Category(id, .): 関数っぽいもの(AからBへの変換を表すもの) *4
- Arrow(arr, first): ？*5
という感じでしょうか、と書いたところで、「知らんがな！」と言われそうですが、理解したい人は本文を読んで下さい :-( これは自分用のメモです。
賢い生徒は定義と例に注目し、特定のメタファーから学びすぎないようにするでしょう。洞察はいつかそれそのものとして得ることができます。
[[Haskell] The Typeclassopediaを訳しました - #3(2009-10-20)より引用]
洞察そのものを得ることができる、って格好よすぎる。いかにも奥義っぽいｗ *6 *7
まとめ
Haskellを使うために数学を学ぶ必要はないが、圏論をプログラミングの世界に応用してる言語はHaskellだけなんじゃないか？
*1 ええ、分かってもらおうとはしていません :-P
*2 あるいは、「Applicativeのうち、文脈をたたみ込める(join)やつ」(でいいのかな)
*3 FoldableはMonoidと関係がある。即ち、畳み込むためには、中身がモノイドでなければならない(ゼロとプラスがないと畳み込めない)。例えば整数のリストは畳み込めるが、時刻のリストは畳み込めない(時刻どうしの足し算って定義できないから)。
*4 Categoryという名前は「圏」(←対象と変換の組)から来ているが、対象はHaskellで扱える型でないといけないから、任意の圏を表せるわけではない…らしい。
*5 これは「○○するもの」という表現がしにくいなぁ。Categoryから条件は増えてないよーな気がするぞ。
*6 一方で、洞察を得てるのに言葉にできないのは単に言葉が足らないだけじゃないか？とも思うけど…数学では良くあることなんでしょうか。感情においては、「言葉にできない気持ち」というものが存在して、それを伝えるために音楽とか、小説が媒体として使われたりするわけですが。
*7 まあ、言葉は理解を「助ける」ことしかできなくて、最後の一歩は君自身が踏まないといけないんだよ、ということかな。
■ [prog][haskell][lisp] HaskellとLispに関する考察
Haskellが将来どうなるかだけど、言葉がアレだけど、現在の(と言っておく)Lispのように、一部の人が奥義としてその恩恵を受けるような存在に留まるのではないかと。
副作用なし＆遅延評価の効能はいろいろあるんだけど、しかしラジカルすぎて広く普及する気がしない。
- 副作用なし、lazy
- HaskellとかCleanとか
- 副作用なし、eager
- これは意味がない気がする (普通の言語で、副作用をなるべく使わずに書けばいいよね)
- 副作用あり、lazy
- これって作れるのかな？
- 副作用あり、eager
- 普通の言語。
一方でLispが広まらないのは言語の外の問題の方が大きいと思っている。例えばもしも90年代初頭に 「スクリプト言語としてLispを使い倒そう」というムーブメントがあれば今とはだいぶ違った世界だったのではないか。
HaskellとLispの大きな違いはもう一つ、Lispの機能(GCなり、クロージャなり、メタプログラミングなり)が他の言語にどんどん取り込まれていくのに対し、 Haskellの本質は副作用なしと遅延評価だから、他の言語が取り込むことができないということ。
…いや、軽々しく本質とかいっちゃダメですね。型システム抜きにHaskellは語れないだろうし。
追記：正直勢いで書いた、今は反省している。do記法でIOが簡単に書けるように、複雑さをうまくラップできればいいですね。
逆に、「副作用なし縛り」でどこまでいけるかを実験してるのがHaskellだとも言える。 GUIライブラリなんかもいろいろ用意されてたりして、 結構いけるみたいですね。
うん、これだけたくさんのライブラリを集めるだけの 力(魅力＆表現力)があるんだから、縮小することはないような気がするなぁ。