前回は入力データにエラーがない場合を想定したコードでした。 今回はデータにエラーが含まれていた場合について考えます。 エラーが含まれていても作動するようにするだけでなく、どんなエラーなのかの説明（ログ）を同時に追加します。

Writer についてこのエントリーで軽く使い方を調べました。 今回はコーヒーの価格改訂を題材にして Writer モナドを使ってみます。

ここでは次のようなケースについて考えてみます。

以下の３つのコーヒーメニューアイテムがあるとします。

• Caffe Americano / 400yen
• Pike Place Roast / 450yen
• Caffe Misto / 500yen

これらが事情により値上げとなり、以下のようになったとします。

• Caffe Americano / 420yen
• Pike Place Roast / 480yen
• Caffe Misto / 580yen

そこで改訂前と後の価格がアイテムごとに把握できるデータを作成します。

• Caffe Americano / 400yen / 420yen
• Pike Place Roast / 450yen / 480yen
• Caffe Misto / 500yen / 580yen

方針として、まずはデータにエラーが含まれていないケースについて考えます（その１）。 その後データにエラー（不備等）があった場合に対処できるコードを Writer モナドを使って書くことにします（その２）。

今回は xlsx モジュールを使って、エクセルデータを書き出します。 前回 までにエクセルデータの読み取りと Computer 型への変換まで行ったので、 今回はその結果をエクセルデータとして書き出します。

前回 に続いてのパート2 です。

前回作成したエクセルデータを読み込むコードをモジュールにした上で、ボディ行を Computer 型に変換するところまで実装します。

xlsx モジュールを使って、エクセルデータの読み書きを試します。

処理内容は、エクセルデータからコンピュータリストを読み取り、所定の条件にマッチした情報のみをエクセルデータとして書き出すことにする。

フォームデータがPOSTされたときのサーバ側でのフォームデータ取得方法 はわかったのだが、GETのときのURLの後ろに追加されるパラメータはどう取得すればいいのか？

フォームデータがPOSTされたときのサーバ側でのフォームデータ取得の記述方法。

前回 ポケモンのモデル化とその進化を Maybe モナドと bind を使って記述しました。 変換処理を連続で適用するという意味では、前回の段階では、コードが読みやすくなった程度で モナドを使う利点がさほどない状態でした。 今回は、ポケモン進化モデルのルールを追加し、モナドを使ううれしさを探ってみます。

Haskell で練習のため キャタピー進化系のモデル化をやってみます。 Maybe Monad を使ってトレーニングとバトルでゲットしたキャタピーを進化させよう。

Twitter にて この電子書籍のアマゾン Kindle 無料サンプルは文字化けした状態であるとのご指摘がありました。 せっかく無料お試しいただいた方、誠に恐縮です。 現在、原因調査および対処中です。 → 解決しました。2022年 3月 4日 18時現在

data とそのフィールド値の取得 でポケモン型を使いました。

そのとき疑問に思ったのが、 たとえば Pokemon をレコード構文で定義した場合に ポケモン型からその名前を取得するのに name aPokemon のようにすれば ポケモン名が取得できることがわかったのですが、name のような、よくありがちな関数名を使えるようにしたら、困るのでは？ということです。

つまり、次にたとえば 進化石 EvolutionStone 型を定義したとして、 そこにも name があったらバッティングして機能しなくなるよね？ ということです。実際にやってみましょう。

前回 pure と Just の違い を調べていて、filterM の Maybe 限定版、というのを考えたのでそれを実際に試した。

Monad においては pure より return を使った方が普通なのかもしれません。わかりません。 Javaなどに慣れていると return は Java の return のイメージになり混乱するので、pure を使うで統一しています（今のところ）。 pure と return どっちなの？という件については https://wiki.haskell.org/Monad を見てください。