タグ

ブックマーク / qiita.com/ruicc (3)

  • モナド則とプログラミング - Qiita

    1. (return x) >>= f ≡ f x 2. m >>= return ≡ m 3. (m >>= f) >>= g ≡ m >>= (\x -> f x >>= g) 等号(≡)は置き換え可能であるという意味で読んでください。上から左単位元、右単位元、結合則と呼ばれます。 モナド則が満たされたモナドはプログラマにとって何が嬉しいのでしょうか。 端的に言ったらコードを分割/組み合わせ/抽象化等が出来るため、嬉しいのです。 もう少し言えば、モナド上では自然にプログラミング出来るから嬉しいのです。 もう少し言えば、モナド上でいつも通りエンジニアリング出来るから嬉しいのです。 モナド則のプログラミング上の意義とは、理解してしまうと当に当たり前になってしまいます。 三日後には嬉しさのことなど忘れてその当たり前のメリットを享受することでしょう。 そうして誰もHaskellのモナド則につ

    モナド則とプログラミング - Qiita
    peketamin
    peketamin 2018/07/07
  • スペースリーク、その傾向と対策

    スペースリークの傾向とその対策を見ていきます。 ここでは3つのパターンを取り上げます。他のパターンがまだ見つかりそうな気がしているので、気がついた方は是非記事を書いてください。 注意事項 「サンクを積む」という表現を多用していますが、「関数適用によってサンクを大きくする」と言った意味合いで使っています。多分に誤用なので外では使わない方がいいと思います(と思ったらそういう表現を使うこともあるそうです) 以前の記事もそうですが、「簡約」は「評価」に統一してます 基方針 追記: 正格評価 無限ループをしない 必要ない式は評価しない 遅延評価 無限ループをしない 必要ある式はサンクを積まない サンクの必要とする空間と、潰した後の空間 サンクは必ずしも悪いものではありません。非常に大きなサンクの場合とそれを潰した場合に、どちらがメモリを消費するかは一概には言えないのです。 少し違いますが、わかりや

    スペースリーク、その傾向と対策
    peketamin
    peketamin 2015/12/08
  • 正格評価と遅延評価(詳細編)

    さて基編に続き詳細編です。 動作を確認しながら細かく見ていきます。 Debug.Trace.trace 初めにtrace関数を導入しておきます。 こんな型の関数です。traceが評価されると、第一引数が標準エラー出力へ出力され、第二引数が返り値として返ります。 このtrace関数が単なる関数だということに注意してください。デバッグ用とはいえ何も魔法は使われていません。IO以外で標準エラー出力へoutputすることから、内部ではunsafeな関数が使われていますが。魔法が使われていない、というのは評価順序に関してです。つまり、trace自体が評価されなければ標準エラー出力への出力もありません。 trace "some string" 42をcaseで評価してみます。 結果は "heyhey!" という文字列が先に現れます。 caseによってtraceは評価され、42がその返り値です。 何が

    正格評価と遅延評価(詳細編)
    peketamin
    peketamin 2015/12/03
  • 1