幅優先探索的にHakellはしばらくスキップ

何となく雰囲気が分かったから、とりあえず何かを書いてみようと思ってHaskellやってみたけど、1時間×3回でコンパイルエラーの嵐で挫折した。というか、何をどうしていいか、すぐに分からなくなる。英語のスペル辞典からアナグラムを探す例題も破綻。やっぱり発想として、データの流れを2本ぐらい想定して、そのデータをいかに処理するか、を考えてしまう。データ中心。Haskellは関数型っていうぐらいだから、関数を中心に考えろってことなのかしら。分からん。

--here's a dictionary file
--
--amass
--assam
--apple
--banana
--amble
--blame
--mabel
--mable
--
--let's turn this into a tuple
--
-- tuple ("aamss", ["amass", "assam"])

import List

main = do cs <- getContents
          print $ hasAnagram sortedList $ map mkPair $ lines cs
              where mkPair cs = (sort cs, cs)
                    sortedList = map fst xs


hasAnagram :: [String] -> [(String, String)] -> [((String, String), Bool)]
hasAnagram sl, [] = []
hasAnagram sl, (x:xs) = (x, (filter (== fst x) sl /= []))  : hasAnagram xs

最初に用意したタプルの3つ目のフィールドに真偽値を入れておいて、これを後から適当にフラグのようにして使えばいいやと思ったりした。

("aelpp", "apple", Flase)

とか。

で、途中まで書いて、あれ、タプルのフィールドにアクセスするのってどうするんだっけと分からなくなった。ていうか、タプルはimmutableなので、フラグを入れておくようなやり方はそもそも間違いなのだった……。

ともあれ、こういうぼくのような挫折感を通して「Haskellのような純関数型プログラミングは難しい」という評判が広がっていくのかなと思った。少なくとも、もう少し例題をたくさんやったりサンプルコードを読まないと「書けなくて当たり前」ということなんだろうけど、経験を積んだプログラマだと、あっさり「これは難しい」と諦めてしまう、とか。

「プログラミング」ということを学ぶために、まず幅優先探索的に表層をなぞろうと考えているので、Haskellはひとまず置いておいて別方面の本を読むのが吉と判断。「ふつうの」シリーズとして、「ふつうのコンパイラをつくろう」（青木峰郎著）を読み始めた。構文解析の話の辺りを読んで、面白いなーと思い始めている。青木さんは、最小限のドライな記述で全体像を読者に見せるのがうまい。