>>720
> 全てのプログラムのパターンを網羅するライブラリは事実上不可能

ライブラリで、将来起きうるすべてのパターンを網羅しろというのは極論では？
学習目的でないなら車輪の再発明は避けるべきだし
よく使うパターンならライブラリ化（抽象化）されるべきだろうという主張に対し
件のご指摘は本末を転倒しています

> そのsmalltalkコードは出力に依存してます

「出力に依存する」ということの意味がわかりにくいのですが
抽出結果を各行逐次出力しているのが気にくわないのでしょうか？

それならそうでない処理の流れにすれば済む話で実際にも容易に書けます
（>>706 の２番目や >>706 の http://ideone.com/xiEftE 、http://ideone.com/RUJP49 ）
当初要求された仕様がどうなっていたか、何を重視するかといった方針の齟齬に過ぎないと思います

逆にたとえばご呈示のHsakellのコードで
メモリに一気には読み込めない巨大なファイルを扱わなければならないとしたら
今の枠組みのまま対応することはできないでしょう？それと同じ話です