筑波大学計算機数学グループ春の館山合宿での講演「数学プログラムを Haskell で書くべき6の理由」の発表資料。実際の講演映像は https://www.youtube.com/watch?v=S4_7KVNA-Ww Read less
![数学プログラムを Haskell で書くべき 6 の理由](https://cdn-ak-scissors.b.st-hatena.com/image/square/ef4edaddce5d6ca3d6a8a739cb2a4aba676e956f/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fslide-140313013841-phpapp01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
この記事はHaskell Advent Calendar 2012用の記事です。 今年はテストに関わる記事が多いように思います。 継続的な開発を行う上でテストは必要なので、テスト手法をキャッチアップしたいと思っていたところでした。まるで渡りに船、いや、ほむらにまどかです。 (追記) QuickCheckで自分で定義したデータ型に対してテストを書きたい場合はこちら QuickCheckでデータがランダムに生成される仕組みについてはこちら QuickCheck テストを書く際、QuickCheckで性質のチェックも行うと思います。 QuickCheckは、 "QuickCheck is property-based tool for random testing." (Arts, 2005) pdf download なるものです。 テスト対象の関数が満たすべき性質を記述し、QuickChec
前回は、ライブラリや実行可能ファイルを提供するパッケージをCabalで作る方法を説明しました。Cabalには、パッケージをテストするための機能も用意されています。今回はこの機能の使い方を説明します。 テスト・プログラムを用意する まず、Cabalのテスト機能を使って実行するテスト・プログラムを用意しましょう。単純に標準出力や標準エラー出力にメッセージを表示するプログラムでは不十分です。テストの結果をきちんとCabalのテスト機能に伝えるプログラムにする必要があります。 第16回で説明したHUnitのrunTestTT関数、第17回で説明したQuickCheckのquickeCheck関数、verboseCheckなどは、標準出力や標準エラー出力を使ってテスト結果を報告します。このため、そのままCabalのテスト機能にテスト結果を伝えることができません。 Cabalのテスト機能では、テストの
テストには常にある種の不安が残ります。このテストは果たしてすべての場合に妥当だと言えるのか? 何か見落としてはいないか? その見落としは致命的なものではないか? Haskellの静的な型検査をすり抜けてくるバグに対処するには,実際にプログラムを動作させ,HUnitなどで動的なテストを行います。では,動的なテストをすり抜けるバグにはどう対処すればいいでしょうか? 一番単純な対策は,テスト項目数を増やすことです。たいていの場合,テスト項目は「その型の取りうる値を想像し,その例に対してきちんと動作するかどうかを確かめる」という形で記述します。単純に考えるなら,テスト項目が増えれば増えるほどテストの正確さは増していくはずです。 しかし,個々の値に対してテストを記述していくのは手間のかかる作業です。テストを行うべき値の集合に対してテストを行うツールが欲しくなりますね。それが「データ駆動型のテスト・ツ
オブジェクトレイアウト 通常のHaskellの値(代数的データ型および関数)と、未評価の計算を表すサンクは、全てポインタで参照される。ポインタが指す先は通常はヒープ上のオブジェクトだが、静的セクションに置かれていることもある。いずれにしてもレイアウトは同じで、以下の一般形をとる。 オブジェクトの先頭1ワードは静的領域へのポインタ(infoポインタ)で、この値を評価(関数なら適用)するためのコード(entry code)と、このオブジェクトの種類に関する情報を集積したレコードを指している。なお、GHCにおける1ワードはポインタと同じ大きさ、つまり32ビットOSなら32ビット、64ビットOSなら64ビットである。これはIntの精度と同じでもある。 代数的データ型 代数的データ型の評価済みの値では、infoポインタが構築子の種類を表し、その後に構築子の引数を入れるスロットが続く。したがって、N引
Redirecting... Click here if you are not redirected.
というタイトルで、先日、社内の公開セミナーで話しました。 発表資料はこちら。 Haskellのテストフレームワークとベンチマークフレームワークがよくできているので、 これをC++でも使えるんじゃないかという内容です。 概要 背景として、QuickCheck をもっと多くの人に知って/使って貰いたいというのがあります。 QuickCheckは、普段から使っている人間からすると、よくいろいろなバグを拾ってくれるとても便利なものなのですが、 残念ながら普段開発に利用しているC++には相当のもので完成度の高いものが見当たりません。 だからといって、そこから作るためにC++のテンプレートをいじくりまわすには、私はもう老いてしまいました (与えられた関数にランダムな入力を与えるだけなら簡単なのですが、ジェネレータを自由にいじれる機能がやはり欲しいところで)。 そう思った時に、FFIを使えてQuickC
この記事の最新版は、githubで管理されています。 これはHaskell Advent Calendar 2012の5日目の記事です。 Haskellで作成したパッケージに対して、単体テストを書くための最新情報をお届けします。 要約 要点は4つです。 利用者に見せたい振る舞いは、doctest で書く 利用者に見せたくない振る舞いは、hspec で書く テストを自動化するフレームワークとしては Cabal を使う doctest でも hspec でも、純粋なコードに対しては、できるだけ QuickCheck などの性質テストを書く この記事で一番伝えたいのは、3) です。例題としては、Base64 という符号化を取り上げます。Base64 は知っていると仮定して話を進めますので、知らない人はあらかじめ Wikipedia の Base64 の説明でも読んで下さい。 この記事で利用するコ
テストって別にやりたくないわけじゃないっていうかやりたいんですけど、なんかつい後回しになってしまうというか。 でも例えば外部システムとの連携部分だったりすると私は割と真面目にテストを書くんですが、普段はなんかなんとなく面倒臭い。面倒くさいと面倒くさくないの境界線は何なんだ。 外部システム連携みたいな入出力系のテストがそれほど苦じゃないのは、どっちにしろ動作確認で動かすからなんですよね。 一方でそれ以外の部分、いわゆる計算というか、モジュール間のデータのやり取りだったりデータ変換だったりとか、そういう部分のテストがなんで面倒くさいかといったら、それは足し算をテストする時の事を考えるとだいたい想像つくと思いますけど、 @Test void testPlus() { assertEqual(plus(1, 1), 2); assertEqual(plus(1, -1), 0); assertEq
たのしいHaskellのツールチェインとC++田中英行 <tanakh@preferred.jp> PFIセミナー 2012/07/19 自己紹介田中英行, @tanakh, http://tanakh.jp PFIで働くプログラマ Haskell愛好家 拙訳「すごいHaskellたのしく学ぼう! 」発売中 本日の概要ソフトウェアテストを取り巻く環境 C/C++のコードをQuickCheckする C/C++のコードをCriterionでパフォーマンス測定する テスト駆動開発Not enough! http://blog.fogus.me/2012/06/20/not-enough/ http://evanfarrer.blogspot.ca/2012/06/unit-testing-isnt-enough-you-need.html Static typing is not enough!
0. 目次 1. 同じ名前のフィールドラベルを持つ型を定義したい 2. モジュールを分割し、階層化する 3. 型の意味 4. 型クラスの役割 5. パラメータ多相と、アドホック多相 6. 多相性とオブジェクト指向 7. 演算子の意味 8. 継承とジェネリクス 9. Ad hoc の意味 10. 型クラスの定義と、インスタンス化 11. 余談: モジュールに分けない場合 1. 同じ名前のフィールドラベルを持つ型を定義したい 2 つの型が、類似している場合、フィールド名に同じ名前を使いたい。 例えば、「名前」と「年齢」を持つ、「犬」型を定義する。 このとき、フィールドラベルを使うなら、 data Dog = Dog {name :: String, age :: Int} deriving Show 「犬」型と同様のフィールドを持つ、「猫」型も定義。 data Cat = Cat {name
ついでに追加。 型推論:変数や式の型をプログラマが宣言しなくても、言語処理系が文脈から推論してくれる機構。MLとかHaskellとか。 型検査:変数や式の型が合っていることを言語処理系が(普通は静的に)チェックしてくれる機構。CとかJavaとか、MLやHaskellも。 静的な型つけ:プログラムの実行前に型を検査する機構。MLとかHaskellとかCとかJavaとか。 動的な型つけ:プログラムの実行中に型を検査する機構。LispとかSchemeとかPerlとか。 強い型つけ:検査を通れば、安全さ(safety)が保証される、という(普通は静的な)型つけ。MLとかHaskellとかJavaとか。Javaはバグがあったりしたので少し怪しいですが。 弱い型つけ:検査を通っても、安全さ(safety)は保証されない、という型つけ。CとかPascalとか。 安全さ(safety):プログラムが言語仕
Haskell Advent Calendar jp 2010のためのエントリです(17日目). 6日目の id:camlspotterさんの 経験15年のOCaml ユーザーが Haskell を仕事で半年使ってみた に対するカウンター(になってるかどうか分からないですが)みたいな感じです. 近くて遠い隣人:HaskellとOCaml OCamlはHaskellと違って副作用があり,更にHM型推論をもつためプログラマは本質的な部分の記述に注力しつつ,コードのチューニングもできる. つまり働くHaskellプログラマがシリアスなソフトウェアを書く時に使えるほとんど唯一の選択肢だ.しかし,同じ静的型付けの関数型言語でありながら,OCamlとHaskellの見た目はかなり異なる. この記事では, HaskellプログラマがOCamlを使い始めると,どういうトラップにハマるかを書く. なかでも,
Haskell's type safety is second to none only to dependently-typed languages. But there is some deep magic going on with Text.Printf that seems rather type-wonky. > printf "%d\n" 3 3 > printf "%s %f %d" "foo" 3.3 3 foo 3.3 3 What is the deep magic behind this? How can the Text.Printf.printf function take variadic arguments like this? What is the general technique used to allow for variadic argument
QuickCheck++は、Haskellで広く使われているテストフレームワークである QuickCheckをC++に移植したライブラリです。 ドキュメントと最新版は以下にあります。 QuickCheck++ Documentation 0.0.2 Version 0.0.2ではsigned/unsigned周りでバグがあるので generate.hhを以下からダウンロードして置き換えてください。 generate.hh さて、では使い方を見ていきましょう。 1.インクルード QuickCheck++はヘッダファイルのみのライブラリなのでインクルードするだけですぐ使えます。 #include <quickcheck/quickcheck.hh> 2.テストするプロパティの作成 以下は、reverseを2回した結果、元に戻るかのテストクラスです。 quickcheck::Propertyクラ
プログラミングの経験はあるが、Haskell は使ったことがない人に、2時間ぐらいで Haskell のよさを教える演習のネタを考える。 Haskell の代表的な利点といえば、 型による厳密なプログラミング QuickCheck によるテストケースの自動生成 Persec によるパーサーの作成 だ。今回は、パーサーの作成は諦めて、上2つについて教えてみる。 リストの探索プログラム まず、連想リストを探索するプログラムを書く。標準では lookup という関数が用意されているが、これを search という名前で再発明する。オーダーは O(n)。 まず、型を考える。 search :: Eq k => k -> [(k,v)] -> Maybe v search = undefined 次に、実装を考える。 search :: Eq k => k -> [(k,v)] -> Maybe v
岡山大学で、関数プログラミングの講義を一コマ担当しました。資料は、函数プログラミングの集いで使った関数プログラミングの道しるべを流用しました。ちゃんと用意しなくて、講義を受けた学生には申し訳ないです。 講義内容に関して質問を頂きました。同じような疑問を持つ人も多いと思いますので、担当教官の許可を得てここに公開します。 永続データプログラミングの意義は分かったが,破壊しないと効率が悪いのではないですか.配列のような構造が世の中には多い気がします.メモリは足りなくなりませんか. 基本的に永続と呼ばれているデータは、共有の効率が高く、しかも不要になった部分はすぐに GC に回収されます。また、GHC の GC はすごく優秀であることが知られています。 Haskell では、下位のレイヤーではデータを破壊できて、たとえば固定長のバッファーを使い回すといったことも可能です。ただ、それは普通のプログラ
Haskellでの BDD を実践するとどうなるかを考えるためのメモ。 型 豊かなデータ型とセクシーな型システムを持つ Haskell では、型が以下のような意味を持つ。 仕様 保守性の向上 簡単なドキュメント 設計図 BDD では、テストの用語ではなく設計の用語を使ってテストを記述する。だから Haskell で、まず型を書く習慣があれば、ある意味 BDD を実践していると言える。この感覚は、他の言語のプログラマには分からないかもしれない。 fromList :: Ord a => [a] -> Set a fromList = undefined このコードはコンパイルを通過するので、型に関する誤りがないことを確かめられる。 僕はへなちょこなので、型を先に書くこともあれば、後から書くこともある。 単純なコードはさっさと実装したい 型は GHC に推測させて、ghc-mod で自動挿入す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く