Persimmonの.NET Core対応

F#

これはF# Advent Calendar 18日目の記事です。 そして.NET Core Advent Calendar 18日目の記事でもあります。 盛大に遅刻しました。

qiita.com

qiita.com

今回はPersimmonという、私が開発にかかわっているF#向けテスティングフレームワークの話をします。

テスティングフレームワークを.NET Coreに対応させるためにやるべきことはいくつかあります。

  1. 本体を.NET Coreに対応させる
  2. test communication protocolに従ってランナーを実装する
  3. 周辺ライブラリを.NET Coreに対応させる

Persimmonはこのうち最初の二つが完了しているので、他に依存のないプロジェクトであれば.NET Core版のPersimmonを試すことができます。

dotnet-test-persimmon

.NET Core CLI用にdotnet-test-persimmonを実装しました。 内部実装はF#非依存です（ランナー自体のテストはF#で書いていますが）。

CLIでの実行は特に問題ないのですが、Visual Studioのテストエクスプローラー連携がまだ若干怪しい挙動なのでお試し程度にどうぞ。

周辺ライブラリ

ほぼ未対応です。 というのも、まだF#自体の.NET Coreサポートの先行きが不透明なので労力を割くべきか決めあぐねているからです。

遅刻したわりに短い記事になってしまった…。

コンピュテーション式の展開結果を可視化するツールComVuを作った

F#

この記事はの13日目です。

qiita.com

今回は過去に作ったComVuというツールの話をします。

https://github.com/pocketberserker/ComVu

nugetでダウンロードできます。

これはなに

ComVuはコンピュテーション式を機械的に展開し、結果を表示するライブラリとツールの総称です。

名前の由来ですが、F#談話室終了後の食事の席で「こういうツールほしい」という話になった際、「こんぴゅてーしょんえくすぷれっしょんびじゅあらいざー…昆布だ！」という流れで決まりました。

ComVu.Coreが解析部分、ComVuがWPFによるツールとなっています。

外部ライブラリの解析

FSharp.Compiler.Serviceを利用してコンパイルや解析を行っているので、#Iや#rを使えば外部ライブラリのコンピュテーション式も解析可能です。

sequence expressionsの疑似展開

sequence expressionsの実装はコンピュテーション式ではありませんが、にたような形式で作れるよという意味合いを込めて展開結果を表示できるようにしています。

問題点

  • 一部のオペレータや関数名の表示が微妙
    • 記号や関数名ではなくCompiledNameで表示されてもわかるでしょ、という気持ちがあったためさぼりました
  • インデント深すぎ
    • YC.PrettyPrinterを使ったらこんな感じに…外部からインデント幅を指定することが簡単にはできそうにないので、独自実装するしかないのかなぁ
  • Windows以外では使えない
    • ComVu.Coreを使えばあとはUIの問題だけなので、どなたか作ってください

余談

作ったは良いものの、私自身はツール無くてもどうにかなっているので拡張する気力があまり起きないんですよね…。 とはいえよさそうな提案があれば実装するつもりはあるので、issueお待ちしています。

2016年時点でF# 用のライブラリを.NET Core対応させるのは時期尚早だった？

F#

この記事はF# Advent Calendar 2016の12日目の記事です。 また、.NET Core Advent Calendar 2016のの12日目の記事でもあります。

結論

先に個人的な結論を述べておきます。

現在のステータス

若干古めですが、GitHub上のvisualfsharpリポジトリのwikiに色々書いていあります。

https://github.com/Microsoft/visualfsharp/wiki/F%23-for-CoreCLR---Status

問題になる点

いくつかのライブラリで.NET Core対応を行った感想です。

  • NuGetのFSharp.Coreに依存させたくない場合は過去と同じ要領でプロジェクトをわけるしかない
    • project.jsonのせい（安らかに眠れ…）
    • NuGetのやつに依存させたくない人は一定数存在する
    • F# 2.0に対応させようとするとこの選択肢しかとれない
  • Visual Studio 2015での開発の厳しさ
    • ハイライト効かない（F# 対応していないので当たり前か）、nugetの挙動が怪しい
    • IDE使わない場合はそんなに苦でもなかった
  • FSharp.Compiler.Serviceが.NET Coreにまだ対応していない
    • わりとネック

これに加えて

  • project.jsonが負債と化すことが確定している
  • TypeProviderはまだサポートしていない
  • Paketもまだ対応できているとは言い難い（？）
    • 9月頃の話。もしかしたら色々と変化しているかも。

といったことを考えると、そこまで急いで対応させる必要はないかと思います。

ただ、AWS LambdaでF#を使うみたいなことをしたい場合、ライブラリが必要なら対応させるしかないでしょうね。

おわりに

まぁ、基本はおとなしくツールが出揃うまで待ちましょう。

F# 4.1から一部のキーワードがunreserveされる話

F#

この記事はF# Advent Calendar 2016の9日目の穴埋め用記事です。

qiita.com

本日はキーワードの話です。

https://github.com/fsharp/fslang-design/blob/8ee13305a7ac559a4c0396681e9501120bbb567e/FSharp-4.1/FS-1016-unreserve-keywords.md

幾つかのキーワードがidentifierとして利用可能になります。 理由は様々ですが（RFCに理由が書かれています）、キーワードとして使うことはないだろうと判断されたものが取り除かれた感じです。

個人的に面白いと思ったのはfunctorですね。

functor - If F# added parametereized modules, we would use "module M(args) = ..."

え、そんなこと考えているの、という気持ちになりました。

F# 4.1からCallerLineNumber, CallerFileName, CallerMemberNameが機能するようになる話

F#

この記事はF# Advent Calendar 2016の7日目の穴埋め用記事です。

qiita.com

今回は標題にあげたCallerLineNumber, CallerFileName, CallerMemberNameの話。

https://github.com/fsharp/fslang-design/blob/8ee13305a7ac559a4c0396681e9501120bbb567e/FSharp-4.1/FS-1012-caller-info-attributes.md

C＃ 5.0から導入されたCaller Information機能がF# 4.1から使えるようになります。

  • 省略可能なパラメータに属性を付ける
    • デフォルト値を定義したいならdefaultArg関数を使いましょう
  • 関数は対象外
    • Optional Parametersはメソッドにしか定義できないので仕方ない

何が嬉しいかって、これのためだけにFSharp.Compiler.Serviceに依存しなくても良くなることですね。

個人的な利用用途の一つにPersimmonでの情報量増加があります。 assertionに失敗した時にファイル名、行番号が簡単にだせるので嬉しいですね*1。

*1:F# 4.1しか表示できない問題は残る

F# 4.1のResult型

F#

この記事はF# Advent Calendar 2016の6日目のものです。 穴埋め用記事です。

qiita.com

今回はF# 4.1から標準となるResult typeの話です。

https://github.com/fsharp/fslang-design/blob/8ee13305a7ac559a4c0396681e9501120bbb567e/FSharp-4.1/FS-1004-result-type.md

ケース名をどうするかみたいな話がありますが、最終的には以下の形に落ち着いたようです。

type Result<'T,'TError> =
    | Ok of 'T 
    | Error of 'TError

また、Resultモジュールにはbind、map、mapErrorが定義されています。

さて、標準から成功/失敗を表す型が提供されたのでめでたしめでたし…というわけにはいきません。

  • ライブラリ側は古いF#ともおつきあいしなければならない関係上、独自のResultやChoiceが消えることは当分ないはず
    • F# 4.1と全く同じ型、関数を提供するライブラリをつくって古いバージョンでも同じように書けるようにする手もあるが、うーん？
  • アプリケーション側はある程度置き換わるはず…とはいえ関数が足りないのでオレオレライブラリが氾濫する可能性は残されている

まぁ、もうすぐ2016年は終了するわけですし、2017年はF# 4.0以下を窓から投げ捨てる覚悟をしても良いかもしれませんね？

FSharp.Control.ImperativeAsyncの紹介

F#

この記事はF# Advent Calendar 2016の8日目のものです。 大遅刻しました…orz

qiita.com

今回はFsharp Bootcamp Tokyo 2016 with Tomas Petricekで議論した結果生まれたライブラリの紹介です。

https://github.com/pocketberserker/FSharp.Control.ImperativeAsync

Asyncでもreturnで大域脱出できるようになるよ、という代物です。

このライブラリではImperativeAsyncという型を用意していますが、ユーザがこの型を明示的に生成することはできません。 あくまで制御用の型です。 中身はAsync<'T option>をラップしただけのものですが、別名をつけておいた方がわかりやすいのでこうしました。

とまぁ、こんな感じで皆さんも気軽にコンピュテーション式を提供するだけのライブラリを作ってみてはいかがでしょうか？