>とりあえず makeRandomValueST から値をどう取り出すかというあたりで四苦八苦という時点でいろいろ終わってる気がするが、とりあえず値の出し方。
>
>newStdGen >>= (return . makeRandomValueST) >>= (\(mt, _) -> putStr $ show mt)
>
>とかやると、ランダムなMyTypeを表示してくれる。頭ではわかっていても、いまだに return は言語要素のような気分でいたからか、 (return .) が出てくるまでだいぶかかった。
>
>ちなみに Hugs はそのままだと Haskell 98 標準に準拠するため、 GHC 独自拡張は動かないから State モナドは使えないらしい。そういうのをやるには hugs -98 などとオプション設定しないとだめらしい。知らんかった。
>
>イヴ、ですねぇ。ていうかもう、クリスマス当日ですねえ。
>
>ケッ。
>
>日本語でわかりやすいと思うので /.-J の記事をば。
>
>PayPal に15ドルほど溜まっていたのがあったので、それを寄付しましたという表明のみです。まあこのマシンもFreeBSDで動いてますからな。
>
>それはそれでひとつの立場だと思います。というより、非常に正しい。
>
>一方で思うのは、 BracketName を採用した場合、とにかくやけに長いページ名、なぜか文章になっているページ名が多い、という不満が個人的にはあります。お前もうちょっと簡潔に書けと。
>
>端的に言えば、前に挙げた例では『あなたの好きな映画を教えてください！』というようなページ名は、『好きな映画』ではなぜいけないのかということです。無駄に長いのではないかと思います。
>
>というのが当初の意図です。
>
>BracketName にはこのような冗長さを簡単に許容してしまうところが確かにあり、構造上制限ができません。とはいえ、制限はしない方がいいのかもしれません。ウィキペディアなどが特徴的ですが、ページ名に任意の文字列が来てほしい場合というのは確かにあります。
>
>さて、当初の WikiName が「CamelCase なもの」と規定されていたように、はじめからページ名に何らかの制約が加えられています。 WikiName の特徴とは何か、というと、簡単にリンクを作ることができるという点に目が行きがちですが、実際には「制約に則りちょっとした変更を加えることにより」という前提が抜け落ちているのではないかと思います。 WikiName は「簡単であること」「言語において存在がちょっとだけ不自然であること(普通の文章は含まない)」「文中に入れてもそれほど不自然ではないこと」という3つの特徴があり、全てがそれなりに有効なのではないかと思います。ところがこのうち二番目の要素はあまり重視されていない。むしろ何らかの制約を設けることによって、ページ名がよりコンパクトにわかりやすくなる方向に仕向けられるかもしれない。
>
>そうした上での日本語の問題は何かというと、わかち書きがされていないため、単語の区切をつけるのが大変で、 CamelCase のように機械的に取り出すものがないということ。むろん、 ChaSen などを使えば取り出すことはできるものの、計算コストが高い気がしますし、取り出したときにどういう並びならばページ名とみなすか、というのも難しい問題です。
>
>そうした時に、なるべくコストが安く済む解決策は何か、ということを考えると、前回の案のうち後者の「単語をアンダーバーでつなぐ」というのは一つの解決策ではないかと考えています。もっとも、実際問題としては、ひらがなを許容すれば、ほとんど BracketName と同じくやけに長いページ名ができてしまうかもしれません。こればかりはやってみないことには。
>
>イメージとしては、 BracketName は「書いた文のうち Bracket を囲む」もしくは、新規ページ作成時にうっかり文章として書いてしまう、というのがあるのに対し、まさしく単語をアンダーバーで「くっつけて」作成する、ということにより、端的な方向への指向性が与えられないか、ということです。イメージですが。
>
>それからこの方式について、国際化対応という観点からすると一見上手く行きそうな気がして自分でころっと騙されかけたんですが、たとえば中国語は漢字と句読点ばっかりですし、韓国語ではハングルと句読点ばっかりですからうまく行かない。日本語のようにいくつもの文字種があるからこそ可能な形式でした。うーむ残念。
>
>そういえば最近、
>FreeStyleWiki
> を使ったことがあるのですが、これはなかなか面白いアプローチを取っていて、既に存在するページ名であれば、特に Bracket で囲まなくてもリンクになるのですね。新規で作るか、または最初だけ BracketName にすればよいという仕様です。また、「この文字列はこのページ名」という対応表を作ることもでき、別の文字列からのリンクもできるようになっている。これはなかなか便利で快適だと思いました。
>
>ただその一方、単純な文字列マッチングを取っているために単語の途中が切取られてしまう問題がありそうな気がしました。また、ページ名が多くなったときに、このアプローチがどれくらい「保つ」のか、というのはちょっと気になっています。
>
>あーでも、はてなキーワードと同じアプローチといえばそうなので、普通の wiki 程度であれば割と行けるのかもしれませんね。
>
>
>モナドのすべて
>
の
>State モナド
>
がわかりません。いやあ、サンプルソースは通読したんですがorz
>
>
>これ
>。
>
>
>1セット揃ったサンプルソース＝例題以上大規模未満、小規模程度の実働プログラム、を通読できれば、あとは自分で小さいのを作る→ちょっと大きいのを作る→もっと大きいのを作る、と頑張るだけである。サンプルソースを通読した後、プログラムができないのは、それは、できないのではない。しないのだ。だって、サンプルと同じに作れば動くんだから。
>
>
>いや、これができないヤツって多いですよね。至言だと思う。
>
>を作って飲む。作り方はいたって簡単。
>
>
>鍋に水を張る
>
>
>
>カップにチョコレート適量を割り入れ、牛乳を適当に注ぐ
>
>
>
>カップを鍋の中に置いて、鍋に火をかけることで湯煎にする
>
>
>
>適当に溶けた頃合いで取り出す
>
>
>
>
>非常に簡便な割に、あったかくて美味。なかなかよろしい。
>
>美味なのは自分の功績でない気もするが、そういう細かいことを気にしてはいけない。
>
>S-Fマガジン、12月号を読了し、1月号にようやく追いついたところですが、感想はもうちょっと先に。
>
>で12月号と1月号に前後編で載ったマーティンの「禍つ星」が滅法面白いです。
>
>辺境惑星に数世代単位でやってきては疫病をもたらすと恐れられている「禍つ星」の伝説。調査の結果、これはオールドアースの残した超兵器の可能性があることがわかり、ついにその居場所が突き止められた。6人の男女がその調査に挑む。
>
>とまあまあいわゆるスペースオペラなんですが、前編の最後で6人がそれぞれの思惑で動きはじめてからが面白い。それぞれがばらばらに行動しながら、各自が自分の思惑で行動しているさまがちゃんと描かれていて、なおかつストーリーがきれいにまとまっていて、伏線もちゃんと回収される。上手いな、と思う。
>
>正直、これ読んではじめて《氷と炎の歌》を読もうかな、という気になりました。でもあれ高いんだよねぇ。
>
>安定して面白い。
>
>と思うんですが、前巻からだいぶ経っているので、基本設定はなんとなく覚えているものの、ストーリーはぜんぜん覚えてなくて困った困った。前巻も家のどこかにあると思うんだけどねぇ……。
>
>まあ4話しか入ってなくて1年待つのはちとつらいですよ、と。
>
>戦隊モノにしては珍しく、イベントっぽくないクリスマスエピソード。というか敵が斬るときに「メリークリスマス」っていうだけ。脈絡なさすぎます。先週の方がクリスマスっぽかったな。
>
>一個のエピソードとしては悪くはないのだが、エージェント・アブレラがいよいよ最後のボスとして本格的に活動を開始する、という段にしてはいまいち。何らかのかたちで、アブレラの大物ブリをアピールする演出がないとなあ。
>
>というか、ボスは道場を継いだのか継がなかったのかがわかりません。
>
>あと「アブレラを倒したときが、本当に勝利の雄叫びを上げるときだ」ってちょっと変じゃないですか。雄叫び？(まあボスが犬だからな)
>
