Haskellがとっつきにくい原因の一つに遅延評価がある。入門書では、無限リストと遅延評価がことさら強調される。しかし、Haskellを業務で使ってみると、遅延評価が煩わしくなってくる。遅延評価なしでもほとんどのことは実現できるし、メモリーの使用量は推測できないし、あまりいいことはない。 Haskellの評価戦略が、他の言語と同じように正格評価だったらよかったのに。 今まで、このようなセリフを何度聞いたか分からない。 そもそも遅延評価が役立つことはあるのだろうか？ ある。お世辞抜きに、少なくとも以下の3つでは本当に役立つ。 リスト(あるいは類似のデータ構造)処理 純粋性に対する暗黙のテスト 効率的なCAS 1.はよいだろう。2.は純粋さを守るために必要だが、コンパイラを開発する人にとって重要なのであり、ユーザには関係ない。3.は、並行プログラミングの奥義である。atomicModifyIO
スペースリークの傾向とその対策を見ていきます。 ここでは3つのパターンを取り上げます。他のパターンがまだ見つかりそうな気がしているので、気がついた方は是非記事を書いてください。 注意事項 「サンクを積む」という表現を多用していますが、「関数適用によってサンクを大きくする」と言った意味合いで使っています。多分に誤用なので外では使わない方がいいと思います（と思ったらそういう表現を使うこともあるそうです） 以前の記事もそうですが、「簡約」は「評価」に統一してます 基本方針 追記: 正格評価 無限ループをしない 必要ない式は評価しない 遅延評価 無限ループをしない 必要ある式はサンクを積まない サンクの必要とする空間と、潰した後の空間 サンクは必ずしも悪いものではありません。非常に大きなサンクの場合とそれを潰した場合に、どちらがメモリを消費するかは一概には言えないのです。 少し違いますが、わかりや
今回からスペースリークに関することに踏み入ります。 まずは正格評価と遅延評価の動作についてです。 型と動的な挙動 まず型についてはここでは触れません。Haskellの型は非常に複雑なものです。型についてメンタルモデルを構築する際もλ計算のシンプルさを念頭におくと非常に理解しやすいとは思いますが、ここでは扱いません。 なので型クラス(type class)や型パラメータ(parametric polymorphism)や型関数(type function)といったものは出てきません。 昔僕も静的な箇所と動的な箇所の違いが見えなかった感覚を少しだけ覚えていますが（スクリプト言語しか書いていないと陥りそうです）、静的な箇所とはプログラムを動作させなくても決定できるところを指すとしましょう。慣れればちゃんと項レベルと型レベルの違いはきちんとわかるものです（ここでは型レベルと項レベルの違いについても
So yesterday I saw someone ask about how many times the variable m gets evaluated in the following Haskell snippet: maxOccurs :: [Int] -> (Int, Int) maxOccurs a = (m, n) where m = maximum a n = length (filter (==m) a) I knew just based on common sense that m only gets evaluated once (when it is first needed, no sooner, no later) but I realised I didn't know the exact mechanics behind that. I grabb
Recently a question by Chris Done on Reddit has spawned yet another debate on the subject of whether Haskell’s laziness is actually a good thing. With this post I’m not going to state my take on the matter, instead I’ll speculate on what Haskell could be like were it a strict language and how it would approach the standard problems. Conditions Deferred Thunk Thoughts on compiler extensions Conclus
This post begins a series of articles about algorithms, inspired by my recent “lazy evaluation” contribution to Lo-Dash. Stay tuned for more! I always thought libraries like Lo-Dash can’t really get any faster than they already are. Lo‑Dash almost perfectly mixes various techniques to squeeze out the most from JavaScript. It uses JavaScript fastest statements, adaptive algorithms, it even measures
Oleg Kiselyov, Simon Peyton-Jones and Amr Sabry: Simple Generators: Incremental stream processing, pervasive in practice, makes the best case for lazy evaluation. Lazy evaluation promotes modularity, letting us glue together separately developed stream producers, consumers and transformers. Lazy list processing has become a cardinal feature of Haskell. It also brings the worst in lazy evaluation:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
