第41回 任意の再帰構造による処理を融合変換できるStream Fusion
前回はStream Fusionを使った融合変換の基礎を説明しました。これだけでもStream Fusionは十分に強力な仕組みですが，Stream Fusionの真骨頂は「fold/buildよりも広範な融合変換がStream Fusionだけでできる点」にあります。fold/buildでは新たに別の融合変換規則を導入する必要がある処理でも，Stream Fusionではそのまま融合変換が可能です。今回は，Stream Fusionの詳細な特徴を説明します。 foldrだけではなくfoldlも融合変換の対象に 第37回で説明したように，fold/buildではfoldrを使って「データ構造を使用する消費者」を定義することで，融合変換可能な優良消費者を用意します。しかし，融合変換の対象を様々な処理に広げていこうとすると，「foldrを使って消費者を定義する」という点が問題になります。 デー
第37回 書き換え規則を使って不要な計算や中間データを除去
プログラムの処理は，いつも効率的であるとは限りません。非効率的な処理があれば，別の効率的な処理に置き換える必要があります。プログラムのアルゴリズムやデータ構造に問題がない場合には，こうした最適化は通常は処理系が行います。 しかし，処理系に実装されている最適化機能は完璧ではありません。プログラマが最適化を行ったほうがいい場合もあります。GHCには，プログラマが最適化の方法を処理系に指示するための「書き換え規則（Rewrite Rules）」という機能があります（参考リンク1，参考リンク2）。 今回は，書き換え規則の基本的な使い方と，GHCに付属するライブラリで使われている最適化テクニックの一部を紹介します。 RULES指示文に書き換え規則を記述 書き換え規則は，「RULES指示文」をソースコードに埋め込むことで利用します。例を見てみましょう。 前回，IntとWordとの間の型変換に，from
第31回 禁断の機能「unsafePerformIO」の深淵
Haskell以外の言語に慣れ親しんでいる人は，プログラムがIOモナドに閉じこめられてしまうHaskellのプログラミングを窮屈に感じるかもしれません。そうした人にとって，unsafePerformIOはこの窮屈さを取り除いてくれる頼もしい味方に見えるでしょう。しかし，unsafePerformIOを気軽に使用すべきではありません。unsafePerformIOは，決してHaskell初心者が期待するようには動作しないからです。 今回は，unsafePerformIOとは一体何なのかを掘り下げて考えてみたいと思います。GHCのunsafePerformIOの実装を例に取り，「unsafePerformIOが実際にはどのように振る舞うか」「unsafePerformIOの使用が問題を起こさないのはどのような場合か」といったことを説明します。 最適化によって振る舞いが変わる なぜunsafeP
関数の話をしよう（1/2）－ ＠IT
第2回 関数の話をしよう 山下 伸夫 株式会社タイムインターメディア 2008/11/28 関数型言語に分類されるHaskell。C言語などの手続き型言語とまったく異なるプログラミングの世界に踏み出してみよう（編集部） Haskellは関数プログラミングのための言語だというのだから、関数が出てこなくては話にならない。今回は、関数の話をしよう。 関数抽象と関数適用 前回、話した標準体重値を計算するパターンは、 （〈身長値〉 ^ 2 ）*〈標準BMI〉 である。〈標準BMI〉は固定された値（22.0）だから、標準体重値は〈身長値〉が変わればそれに応じて変化する。標準体重値の計算は、 （〈？〉 ^ 2 ）*〈標準BMI〉 の〈？〉の部分を具体的な身長の値で「置き換え」てやればいいということになる。〈？〉を一種の穴のようなものだと考えれば、そこへ値をはめ込めばよいわけである。 この計算パターンを、
Haskellプログラミングの楽しみ方 − ＠IT
第1回 Haskellプログラミングの楽しみ方 山下 伸夫 株式会社タイムインターメディア 2008/10/29 関数型言語に分類されるHaskell。C言語などの手続き型言語とまったく異なるプログラミングの世界に踏み出してみよう（編集部） 本連載は、Haskellプログラミングの初歩から始めて、日常的なスクリプティングやWebプログラミングをHaskellで楽しめるようになるまでのガイドである。 Haskellプログラミングのスタイル Haskellプログラミングに興味はある人でも、Haskellプログラミングの習得にはちょっとした障壁を感じることがあるのは間違いないようだ。小難しい概念や用語のせいでもあるが、それらはあまり重大な理由ではない。 障壁となるのはHaskellのプログラミングスタイルである。Haskellのプログラミングスタイルは関数プログラミングという系統に属する。一方、
第23回 外部環境のメモリーとHaskellの間の整合性を取る
前回はFFIのごく基本的な使い方について説明しました。実際のプログラミングでFFIを用いる場合には，もう少し突っ込んだ知識が必要になります。「Haskell内部の環境と，FFIを使って呼び出されるべき外部の環境との違い」，これをどのように解決するかを考えなければなりません。 こうした違いには「リソースの管理」「スレッド」「例外の扱い」などがあります。今回はリソースの管理を取り上げて説明しましょう。 GCにリソースの管理を任せる 通常のHaskellプログラムでは，ガーベジ・コレクション（GC）によって使用されなくなったメモリーが適宜解放されることが保証されています。このため，確保されたメモリーが解放されないまま残ってしまうことはありません。 では，FFIを使って呼び出す外部関数が扱うメモリーについてはどうでしょうか？ 外部関数が使うメモリーをどのように扱うのが適切なのかは，個々のケースで異
第15回 Haskellでのデバッグのコツをつかむ
プログラムが思った通りに動かないとき，あるいは他の人が書いたプログラムを理解したいときには，プログラムの挙動を調べてみるでしょう。例えば，「入力」に対する「出力」を調べたり，プログラムが保持する「状態」を確認することで，挙動を理解しようとするはずです。そうしたときに使う手法が，プログラム動作中の変数の値といった情報を適宜出力する，いわゆるトレース（trace）です。C言語では情報の表示によくprintfを利用することから，printfデバッグとも呼ばれます。 Haskellでトレースを使うには，二つの問題があります。一つは，Haskellの型は必ずしも値を表示できるものばかりではない点です。これは回避が容易なので，さほど問題ではないでしょう。より深刻なのは「Haskellでは，副作用によるバグの発生を防ぐために，I/Oの扱いに対して制約がある」という点です。この結果，Haskellではトレ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
