2010年3月22日に,Haskell Platform 2010.1.0.0がリリースされました(参考リンク1,参考リンク2)。
Haskell Platformは,その名の通りHaskellでプログラミングをするユーザー向けの開発プラットフォームです。Haskell Platformには,GHCに加え,GHCには含まれていないライブラリや,cabalコマンド(cabal-install)などのツールが収録されています。
Haskell Platformが生まれた理由
Haskell Platformは,Haskell処理系であるGHCに加え,実際のプログラミングで必要になるライブラリやツールなど,Haskellによるプログラミングを行うのに必要な環境一式を提供するものです。ただし,Haskell Platform 2010.1.0.0のリリース時点では,どのOSを使用しているかによってインストールの方法が異なります。
Linuxの一部のディストリビューションやMac OS X用のパッケージ管理システムであるMacPortsでは,haskell-platformというパッケージが提供されています。このパッケージを利用することで,Haskellプログラミングに必要な環境を一括してインストールできます。ただし,パッケージ管理システムの性質上,最新版の反映が遅くなることがあります。
こうしたパッケージ管理システムを使わない場合には,それぞれのOS向けに提供されているHaskell Platformのパッケージを利用することになります。
Windows向けには,GHCやライブラリ,ツールなどを一括してインストールできるバイナリ形式のインストーラが提供されています。
Mac OS X向けには,GHCのインストーラとHaskell Platformのインストーラをセットにしたバイナリが提供されています。このバイナリをダウンロードし,GHC 6.12.1のインストーラを実行してインストールした後,Haskell Platform 2010.1.0.1のインストーラを実行します(バグ修正のため,Mac OS X版のバイナリのバージョン番号は2010.1.0.1になっています)。
なお,今のところ,Mac OS XのインストーラではHaskell Platformでインストールされるツールに対するパスは設定されません。cabalコマンドなどのツールを利用するには「/Library/Frameworks/HaskellPlatform.framework/bin」をパスに設定する必要があります。また,Haskell Platform 2010.1.0.1のバイナリでは,Snow Leopard以前のMac OS Xでcabalなどのツールを利用できないという問題があります(参考リンク)。
Haskell Platformはソースコードも提供されているので,ソースコードからビルドすることも可能です。ただし,このソースコードにはGHCは含まれていません。前もってGHCをインストールしておく必要があります。
ここまでの説明を表にまとめると,以下のようになります。
インストール方法 | GHCの事前インストール | 注意点 |
---|---|---|
Windowsバイナリ | 不要 | なし |
Mac OS Xバイナリ | 必要(別々にインストール) | 環境変数が未設定 |
ソースコード(Unix環境向け) | 必要 | なし |
パッケージ管理システム | 不要 | 最新版の反映が遅い |
では,Haskell Platformで追加されるライブラリやツールを見ていきましょう。
shelarcyMacBook:~ shelarcy$ ghc-pkg list /Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.1/package.conf.d Cabal-1.8.0.2 GLUT-2.1.2.1 HTTP-4000.0.9 HUnit-1.2.2.1 OpenGL-2.2.3.0 QuickCheck-2.1.0.3 ~ 略 ~ cgi-3001.1.7.2 containers-0.3.0.0 ~ 略 ~ fgl-5.4.2.2 ~ 略 ~ haskell-src-1.0.1.3 ~ 略 ~ html-1.0.1.2 ~ 略 ~ mtl-1.1.0.2 network-2.2.1.7 ~ 略 ~ regex-base-0.93.1 regex-compat-0.92 regex-posix-0.94.1 ~ 略 ~ stm-2.1.1.2 ~ 略 ~ xhtml-3000.2.0.1 zlib-0.5.2.0
Haskell Platformでは,OpenGLやnetworkなど多くのライブラリが提供されています。実は,これらの多くは,以前はGHCに付属していたものです。なぜ,こうしたライブラリがGHCから削除され,Haskell Platformという形で提供されることになったのでしょうか?
実は,Haskell Platformが登場する前から,GHCに標準で付属するライブラリを減らす試みが続けられてきました(参考リンク)。それを補うために,処理系にライブラリをインストールするための基盤も整備されてきました。パッケージの作成やインストールを行うためのシステムであるCabalパッケージやcabalコマンド,パッケージを提供するサイトであるHackageDBなどです。
GHCの軽量化が必要な理由の一つは,GHCのビルドにあります。GHCのビルドでは,GHCが単体でビルドされるわけではありません。GHCに付属するライブラリを含む形で,一緒にビルドされます(参考リンク)。GHCに多くのライブラリが付属していると,GHCをビルドする時間が長くなってしまいます。また,GHCの変更やライブラリの変更によってライブラリが壊れた場合,GHCのビルド全体が失敗してしまうことになります。付属するライブラリが多ければ,それだけビルドが失敗する可能性が高くなります。こうした問題を避けるには,GHCとともにビルドされるライブラリの数を最小限に抑える必要があります。
もう一つの理由は,ライブラリのバージョンアップです。ライブラリがGHCに付属していると,GHCのバージョンが上がったとき,付属するライブラリもGHCに合わせてバージョンアップします。ライブラリの新しいバージョンで,以前のバージョンとは互換性がない変更が加えられていた場合,GHCのバージョンを上げると,GHC側の変更とは関係なく,そのライブラリを使っていたプログラムが動かなくなる可能性があります。
この問題を避けるには,GHCに付属するライブラリを極力抑え,処理系とライブラリのバージョンアップを別々に行えるようにする必要があります。処理系とライブラリのバージョンアップが分かれていれば,処理系のバージョンアップを待たなくてもライブラリをバージョンアップできます。ライブラリが,旧バージョンと新バージョンの両方のGHCに対応すれば,プログラムを新しいGHCにスムーズに移行できます。
もっとも,GHCに標準で付属するライブラリを減らすと,利便性はどうしても落ちてしまいます。付属していないライブラリを使いたければ,後からインストールする必要があるからです。OpenGLやnetworkといったパッケージは,Windows環境ではインストールが面倒です。
特に問題なのがcabalコマンドです。cabalコマンドのビルドには,GHCに付属していない多くのライブラリが必要です。このため,cabalコマンドをGHCに付属させることは,付属ライブラリ軽量化の流れに反します。一方,cabalコマンドがなければ,付属ライブラリを減らすことでGHCが使いにくくなってしまいます。
こうした問題を解決するため,GHCのリリースとは別に,GHCにライブラリとツールを追加したHaskell Platformが提供されることになったのです(参考リンク1,参考リンク2)。
Haskell Platformの登場により,GHCの付属ライブラリの軽量化と,Haskellプログラマ向けの広範なライブラリやツールの提供を両立できるようになりました。Haskell Platform 2010.1.0.0の時点では,まだ付属するライブラリやツールは少ないですが,今後は拡充されていく見込みです。
ここで,Haskell Platformのバージョン番号の規則を説明しておきましょう。
「2010.1.0.0」の最初の「2010」という数字は,リリースされた年を表します。次の「1」は,リリースされた年の何番目のメジャー・リリースであるかを示します。月を表すものではないので注意してください。Haskell Platformでは,メジャー・リリースは半年ごとに行われる予定です。つまり,Haskell Platformの次のメジャー・リリースは「2010.2.0.0」,その次のメジャー・リリースは「2011.1.0.0」になります。
残る二つの数字は,マイナー・リリースを示すものです。Haskellコミュニティでは,互換性を保ちつつ新しい機能(API)を追加するときに三つ目の数字を上げます。最後の数字は,バグ修正だけを行った場合に上げます(参考リンク1,参考リンク2)。