フォームデータが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 を見てください。

前回 コンピュータリストを bind ( >>= ) を使って連続して条件を適用しました。

しかし、コードをよく見てみると、 Just の部分を pure に変更しても作動するし、その逆に pure の部分を Just に変えても作動する。 今回はその謎を調べます。

前回 のコンピュータリストを使って、フィルタとモナドを試します。

Haskell に慣れるため、Koltin と比較しながら、身近な題材を使ってあれこれやってみます。

前回 ポケモン型を使いましたが、そのフィールドを取得する方法を整理します。

Haskell では data Product = Product String Int のようにしてデータ型を定義できる。 これがただの関数だという。 どういうことかわかった（気がする）ので、書き留めておく。

Haskell での Map 操作の覚え書き。 身近なポケモンを使ったコードをつくります。