>>712
それって結局ライブラリが揃っていて、探しやすければオブジェクト指向とか構造化プログラミングとか関数型とかのパラダイムはどうでも良いって言ってる様なものだなと。
そして、実際その通りなんですが、全てのプログラムのパターンを網羅するライブラリは事実上不可能です。
Delphiのコンポーネントでpascalインタプリタがあってポトペタで一行のコードも書かずにpascal処理系を作れたとしても。
結局どの言語もライブラリの関数なりクラスなりを組み合わせます。
smalltalkは検索しやすい方向へ進化し、Haskellは自作しやすい方向に進化したんじゃ無いかと。

そのsmalltalkコードは出力に依存してますが、私もRubyやPythonでよく書きます。
Haskellの場合は強制的に出力に依存しないコードになるので、number.hsのコードの最後の行を

mapM_ (putFileContent.(\(f, c) -> (f, searchWord word c)))

の様にputFileContentの受け取る値を横取りしてsearchwordコマンドを作っても良いです。
型さえ考慮すればnumbering以降から出力直前まで、好きな段階でsearchWord関数を使えます。

numberingとsearchWordそれぞれlines/unlines使ってるので汎用性高い代わりに無駄な処理も多いと言うなら、汎用性を犠牲にしてsearchWordにnumberingの中身を入れてしまえば良いです。

この様に特異な発想？にも柔軟に答えてくれます。