新しい言語を触り始めた時に実装してみるもの一覧
ajitofm 13に「言語を学ぶ時に練習で何を実装してみるか」みたいな話が出ていた。 で、自分は何やっているかなーと思ったので書き出してみる。
全部やるってわけではなく、目的に応じていくつかやってみる感じ。
- parser combinator
- パフォーマンスを求めないなら数日で実装できる
- 文字列操作
- 最適化の練習（文字列編）
- JSON serializer
- parser combinatorを使って何かやってみる時の定番？
- quickcheck的なライブラリを練習するのにちょうど良い
- binary serializer
- バイナリ操作
- マクロ
- 最適化の練習（バイナリ編）
- msgpackが仕様の大きさ的にやりやすい？
- データ構造
- ひとつひとつは小さいので練習しやすい
- データ構造、アルゴリズムの復習を兼ねる
- TODOリスト
- Webフレームワーク
- DB
- logging
- テスティングフレームワーク、アサーション
- リフレクション、メタプログラミング
- AST変換（power assertもどきを題材に）
- 同値比較の考察に便利？
- 完成度は重視しない
他の人がどういうことをやっているのか気になるところ。
技術書典3で F# 入門的なものをだします
そういえば今回はえ１４でいい場所っぽいです。もみあげ@pocketberserkerさんと共同スペースで前出したコンパイラ本の完全版を出します（予定https://t.co/LZfLZQg5OK
— インターネットの闇 (@no_maddo) 2017年9月23日
なんとかまにあってよかった…。
表示はこんな感じ
高階ことりちゃんの画像は以下のサイトからお借りしました。 CC BY-SA 3.0だそうです。
内容としては.NET Core 2.0でF#に入門する的なものになります。 といっても半分くらい文法説明です。
500円の予定です。 今のところ電子版の予定はありません。
Utf8Json.FSharpExtensions 0.1.0を試験的にリリース
ある朝、目が覚めたらUtf8Jsonのリリース話とともにメンションが飛んできていました。
例によってF#対応は @pocketberserker さんに投げ（
— neuecc (@neuecc) 2017年9月27日
ほげぇ、と言いつつ簡単な部分だけ作ったので公開しておきます。
NuGet Gallery | Utf8Json.FSharpExtensions 0.1.0
0.1.0で対応しているのは以下の型です。
- Option
- list
- set
- map
recordとstruct recordは別に上記ライブラリを使わなくても動きます。
判別共用体は対応するか悩み中です。 そんなに使うのかなぁ、というのが悩んでいる理由です。 でもJSON.NETはサポートしているらしいんですよね…うむむ。
vstestで.NET Coreプロジェクトのコードカバレッジをとる
temporary workaroundらしきものがドキュメントにのっていたのでメモ。
こっちのissueが解決されれば、dotnet testコマンドで実行できるようになるようだ？
https://github.com/Microsoft/vstest/issues/981
とはいえ現時点でスケジュールが確定していないので、vstest.console.exeを直接叩くこの方法とは長い付き合いになりそう。
F# で使われるユニットテスティングフレームワークなどの紹介
前にもかいたことがある気がするけれど、2017年度版ということでどうか。 "フレームワーク"と書きつつライブラリも混ぜます。
NUnit
- よくみかけるやつその1
- 古の時代から存在するとされている
- 最近になってウェブサイトがモダンに
- 地味に進化を続けている
- .NET Coreに対応している
最近だと
今更だけどNUnitにMultiple Assertってのが追加されてた。便利やん。https://t.co/dWNF8CNUUD
— miyazaki (@htid46) 2017年9月22日
という話を見かけて「へぇ〜」っとなった。
しかしこのAssert.Multipleはどうやって動いているのだろう…？
個人的にもう使う機会はないだろうと思いつつ、なんだかんだ参考になることがあるのでソースは読むだろう。 なんとかUnitに慣れている人ならかける。
xUnit.NET
- よくみかけるやつその2
- .NET Foundationのもちもの
- .NET Coreに対応している
コミュニティ的なリソースがあるためか、開発速度がダントツで早い気がする。 .NET界隈（特にC#界隈）のデファクトになる（なっている？）のではないでしょうか。
個人的には、F#製ではないフレームワークの中でならAssertionが好みなのでこれを選ぶ。
MSTest
https://github.com/Microsoft/testfx
- かつてVisual Studioに標準搭載されていたやつ
- .NET Coreに対応している
特筆すべきことはない…私が知らないだけかもしれませんが。 新規で使う理由も、特にない…？
FsUnit
https://fsprojects.github.io/FsUnit/
- NUnitやxUnit.NETといったどちらかといえばC#, VB.NET向けフレームワークのAPIをラップしたもの
- FsUnitTypedというモジュールを使えばAssertionの型チェックを厳密に行える
F# 界隈では一時期みんなこれを使っていたような…今はどうかわからない。
個人的には、shouldみたいなAPIを覚えていられない記憶力になったので使わないと思います。
FsCheck
https://fscheck.github.io/FsCheck/
- Propery Based TestingとかRamdom Testingとか呼ばれる類のツール
- 一応単独で実行できる仕組みがある
- とはいえ、他のテスティングフレームワークと組み合わせる場合がほとんど
Persimmon以外のテスティングフレームワークなら使わない選択肢がない。
expecto
https://github.com/haf/expecto
- 最近話題にのぼることが多い気がする
- F#向け
- 確かFuchuというフレームワークのfork
- いろんな機能がある
- https://github.com/adamchester/expecto-adapter を使えば.NET Core SDKでも実行できるはず
後述するPersimmonとは違う意味で独特なAPIです。 コンピュテーション式を使い分けることでSync、Async向けテストをかき分けられる。
私にはPersimmonがあるので使わないですが、興味がある方はさわってみると良いかも。
Persimmon
http://persimmon-projects.github.io/Persimmon/
- F#向けというかF#専用
- APIが独自路線な関係でいろんなライブラリを再実装している
- .NET Coreでも一応動く
- コア開発者が日本人
ライブラリはなぜか色々ある。 名前と機能の関連がわかりにくいという噂あり。
開発者バイアスがかかるので所感は書きません。
unquote
http://www.swensensoftware.com/unquote
- F#でpower assertしたい的なやつ
他言語のpower assertに比べるとちょっと見劣りする気がしなくもない…？
canopy
http://lefthandedgoat.github.io/canopy/
- Web UIテスト
F#でかけるよやったね、以上も以下もない気がする。
Foq
https://github.com/fsprojects/Foq
- テスティングフレームワークと書いてあるが、モックライブラリと認識している人が多い気がする
おわり
数年前に比べて選択肢は増えたが、まだまだ競合が少ない気がする。
Persimmon.Script 2.0.0をリリースした
NuGet Gallery | Persimmon.Script 2.0.0
Persimmon v2を作る過程で「使う人いないし消そう」となってdropしたのですが、最近になってほしいという人が現れたので、v2ようにマイグレーションするくらいなら労力かからないだろうということで復活させました。
まぁ、労力は予想以上に必要でしたが…1日で終わると思ってたら色々試行錯誤したりで3日くらいかかってしまった。
使い方は簡単で
#r @"../packages/examples/Persimmon/lib/net45/Persimmon.dll" #r @"../packages/examples/Persimmon.Runner/lib/net40/Persimmon.Runner.dll" #r @"../src/Persimmon.Script/bin/Release/net45/Persimmon.Script.dll" // このあたりにテスト書く Script.collectAndRun (fun _ -> Assembly.GetExecutingAssembly())
Script内にテストを書き連ねた後にAssembly.GetExecutingAssembly()でスクリプト自身のAssemblyをターゲットとしてテストを収集、実行するだけです。
個人的にはテスト用のdll作ってしまうので使う機会がなさそう…ということもあってメンテナンスを継続するかどうかは期待しないほうが良いです。 あくまでdll作ってテストするまでもないもの（そんなものあるのか…？）に対して使用しましょう。
呪文詠唱！F# #ML_study
発表してきました。
要約
F#のコンピュテーション式を使うと呪文詠唱できます。 呪文詠唱自体に実用性はありませんが、やっていることは応用が効くかもしれません。
はじめに
突然ですが問題です。
詠唱 { モナドは 単なる 自己関手の 圏における モノイド対象だよ 何か問題でも ``?`` }
このコードはF#的にvalidでしょうか？
正解
コンピュテーション式用のビルダークラスを適切に準備してあげればvalidになります。
中身
MLStudy2/Program.fs at 78359cf52503daa0c40cf5fed50a60dc89e5c9df · pocketberserker/MLStudy2 · GitHub
要するものは以下のとおり
- コンパイルできるコードを制限するための型
- 名前はなんでも良いので、今回は
Line0とかつけてます - 別に判別共用体でなくても良いですが、シングルトンを作りやすいものが良いでしょう
- 名前はなんでも良いので、今回は
- Attributeから値を取得するためのヘルパー関数
- カスタムオペレーター用のメソッドに指定したAttributeを取得し、そこから情報を抜き出します
- カスタムオペレーターが定義されたコンピュテーションビルダー
- カスタムオペレーターを使うことで、任意の文字列をコンピュテーション式のキーワードとして扱える
- 中身はなんでも良い
- 今回は呪文詠唱っぽくみえるよう、1秒ごとに呪文を出力している
Runでコンパイル制限用に使っていた型の値を取り除く
コンピュテーション式は、展開規則に従ってビルダーに存在するメソッド呼び出しに展開されます。
この時、引数や戻り値の型を適切に実装すればあるオペレーターが呼ばれない限りコンパイルエラーとか、指定の順序で呼び出さない限りコンパイルエラーとなるようにできます。
今回のコンピュテーション式は呪文なので、カスタムオペレーターの呼び出し順序は固定です。 呪文は少しでも間違えると発動しない（つまりコンパイルエラー）なのは当然ですよね？
無詠唱
発表中は「無詠唱なんて許さない」と言いましたが、つくれないことはありません。
ビルダーにZeroメソッドを用意することで、無詠唱のようなことが行えます。
詠唱 { () }
Zeroメソッドを定義する際の注意点は以下のとおりです。
- ビルダークラスに定義されたカスタムオペレーター用のメソッドを全て取得
- 上記実装はザルに作ったので実行順序が処理系依存ですが、詠唱順序をちゃんと固定したいなら、メソッド名をソートしやすいものにしたほうが無難
- キーワード名とメソッド名は別でも問題無い
- デバッグ時にわかりやすくするために名前を合わせることが多いとは思う
コンピュテーション式用のビルダーを生成できないのか？
ファイルから読み込んだ文字列群を用いてTypeProviderでビルダーを生成すれば、任意の詠唱を生成できるのでは、という話をしました。 残念ながら当日には間に合いませんでしたが…。
で、これについて昨日検証してみたところ、現場のコンパイラだと不可能っぽいという結論に至りました。
- 必要なビルダークラスとメソッド、型までは消去型なら用意できる
- 生成型は複数の型を生成できる気がしない…
- 生成したビルダーのカスタムオペレーターがコンパイラにカスタムオペレーターだと認識されない
もしかしてコンパイラのバグだったらどうしよう。
コードは公開しているので、検証したい方は好きにいじってください。
補足？
— κeen (@blackenedgold) 2017年7月22日
Indexed MonadをF#で用意できるのかは不明ですが、やりたいことは同じかと。 今回は時間がなかったのでごり押しでコードを書いてしまいました。
まとめ
言語機能を使って遊ぶのはとても楽しいです。
