タグ

kazu-yamamotoに関するUSAGI-WRPのブックマーク (5)

  • コンパイルは(テストではなく)証明である - あどけない話

    「プログラムのテストはバグの存在を示すことにかけてはとても効率的な方法ですが、バグの不在を示すことにかけては絶望的なほどに不適切です。プログラムの信頼性を顕著に向上させる唯一の方法は、その正当性に対して説得力のある証明を与えることです」 -- Edsger W. Dijkstra 静的型付き言語では、コンパイル時に型が検査される。この型検査に関連して型推論という機能を持つ言語がある。型推論は、大きく分けて2つの意味で使われているようだ。 命令型言語の多くに見られる型推論:型検査の過程で、省略された型を補うこと 関数型言語の多くに見られる型推論:未知の型を変数として方程式を立て、方程式を解いて未知の型を求めること。型推論自体が型検査の役割を果たす この記事では、後者の型推論を話題にする。 静的型付き関数型言語の利点として、よく「コンパイルはテストである」という説明がなされる。プログラムは式で

    コンパイルは(テストではなく)証明である - あどけない話
  • なぜ Haskell ではキューが軽んじられているか? - あどけない話

    Haskell ではキューが欲しくなったら Data.Sequence を使えと言われる。Seq は両端キューだし、シーケンスとして使えば、連結(><)や分割(splitAt)が、ならし計算量で O(log N) という優れものである。しかし、内部がfinger treeなのでコードが複雑なのと、計算量が「ならし」なところが玉に傷である。 もっと単純で、最悪計算量を保証する(両端でない)キューが標準で提供されてもいい気がする。その候補には、リアルタイムキューがある。どうして標準でキューが提供されないのだろう? 僕なりの答えは「需要がない」だ。 問題を解くときにスタックはよく使うが、キューが必要な問題はそんなに思いつかない。僕はネットワーク屋なので、もちろんルータにはキューが必要なことは知っているが、それ以外で有名どころと言えば幅優先探索ぐらいだ。 幅優先探索 でも、Haskellではキュー

    なぜ Haskell ではキューが軽んじられているか? - あどけない話
  • recursion.gby

    1 @kazu_yamamoto 2 3 Haskell = gcd :: Int -> Int -> Int gcd a 0 = a gcd a b = gcd b (a ‘mod‘ b) 4 sum :: Num a => [a] -> a sum [] = 0 sum (x:xs) = x + sum xs sum (x:xs) = (+) x (sum xs) 5 6 (1) sum :: Num a => [a] -> a sum [] = 0 sum (x:xs) = x + sum xs sum :: Num a => [a] -> a sum is = sum’ is 0 where sum’ [] a = a sum’ (x:xs) a = sum’ xs (x+a) 7 (2) ) = (+) fib :: Int -> Integer fib 0 = 0 fib 1

  • Haskell でのデバッグ - あどけない話

    「純粋関数型言語はデバッグしにくい。だって純粋な関数で printf デバッグできないから」とつぶやいている人をよく見かけます。これまで放置してきましたが、リツイートが50を超えたので、Haskellでのデバッグについて書きます。 例外処理と同じように、Haskell でのデバッグでは、純粋な関数と IO を分けて考える必要あります。 IO での printf デバッグ IO では、putStrLn や print が使えるから問題ないですよね? foo :: Int -> IO Bool foo i = do x <- あれして i putStrLn $ "x = " ++ show x これして putStrLn "ここも通過" -- それもする y <- それもする print y return y ちなみに、forkIO 起動した軽量スレッドから putStrLn する場合、軽量ス

    Haskell でのデバッグ - あどけない話
  • Haskell での例外処理 - あどけない話

    リツイート数が30を超えたので、Haskell での例外処理について説明します。僕が思うに、Haskell での例外処理が分かりにくいのには、2つ理由があります。 ライブラリの混乱 パラダイムの違い 歴史的経緯により、Prelude にも Control.OldException にも Control.Exception にも catch があります。歴史的経緯を説明するのは面倒なので、これだけ覚えて下さい。「Control.Exception だけを使って、それ以外は忘れる」 そもそも純粋関数型で catch とか言われても分からないかもしれません。Haskell では、純粋な関数と IO とでは、例外処理の方法が異なります。命令的な catch などを使うのは IO です。純粋な関数には Maybe か、Either を使います。 純粋な関数 純粋な関数では、原則として例外を投げてはい

    Haskell での例外処理 - あどけない話
  • 1