ScalaやHaskellのライブラリをF# に移植するときのTips？

F# Haskell Scala

こんなことを思っていたりすることもあるため、HaskellやScalaに面白そうなライブラリがあると聞きつけるとF# に移植できないか試したくなります。

で、いくつかTipsというかこんなことがあるよ、的なことをまとめておきます。

用語はてきとーなので表現が微妙であれば順次修正していきます。

【この記事は書きかけです】

型パラメータが型パラメータをもつ

Free Monadを例にしてみると

sealed trait Free[S[+_], +A]

や

data Free f a = Pure a | Free (f (Free f a))

などの型パラメータが型パラメータをもってるよ的なやつです。

これが出た場合、私は白旗をあげます。

型エラーが解決できない

基本的には多相ではないのであきらめなければらなない場合か、解決できそうだけど根気負けする場合の2択です。

obj型なら通る、とかもたまにありますね。

再帰なlazyちゃんマジlazy

これはscala-machinesやHaskellのmachinesのrepeatedly関数を例にしましょう。
まずはScala。

def repeatedly: Machine[K, O] = {
  lazy val r : Machine[K, O] = this >> r
  r
}

次にHaskell。

repeatedly (Plan m) = r where r = m (const r) Yield Await Stop

lazyだからこそできる再帰ですね。

HaskellやScalaではlazyが型に現れることはないので、これで問題なしです。

が、F#ではこう単純にはいきません。この例の場合だと、

let rec repeatedly p : Machine<'k, 'o> =
  let inline (>>.) p (next : Lazy<Plan<'k, 'o, 'a>>) = p >>= (fun _ -> next.Value)
  let rec r = lazy (p >>. r)
  r.Value

こうなります。

まずevaluationが発生して欲しい場所を探します。今回の場合は(>>.)演算子でした。
これを、えいやっとシャドウィングしてLazy版を書きます。
あとは何事もなかったように、自己再帰の警告を #nowarn "40" などで消すなり放置しながら残りの部分を実装します。
こうすることで、他の関数には迷惑をかけずにScalaやHaskellと同様のことが行えます。

この系統はlazy evaluation(?)の良い勉強になりますね。

type class

  1. fsharp-typeclasses - Emulate Haskell's typeclasses in F# - Google Project Hosting を使う
  2. あきらめて地道な実装を行う

前者は使ったことがないのでどんな感じなのかわかりません。

後者はFSharpx内のいくつかのmoduleに方法を見れば、どんな感じなのか把握できると思います。

あ、IOモナドはあきらめてます。

Nothing型

ScalaのNothing型を表現できる気がしないので、コンパイラのご機嫌を伺いながら(型推論してもらいながら)問題のなさそうな型にします。

おわりに

「F#で理想を追求するって、そういうことよ」

F# にMachinesの移植を試みている

F#

某都会ではekmett氏のライブラリを勉強する会があるらしい。

http://partake.in/events/1698f7f8-4151-4048-b317-03a8c3f1a7ab

うらやましいとかそういうことはすごくあるのだけれど、行けないものは仕方がないので自前環境でとりあえずは我慢することに。

本題

というわけでmachinesをF#に移植しようと試みている。

Haskellのmachinesは見た感じF#への移植は難しそうなので*1、scala-machinesを主に参考にしている。

まぁ、現状色々と嵌ったり詰ったりしていますが。。。

特に型周りがちょっときつい。今はこのあたりでとまっている。

Gists

目下の戦いはこの部分。

def left[A]: Handle[T[A, Any], A] = \/.left(_)

Handle部分を展開すると A => A \/ Nothing という解釈であっているのかな？
正しいならそれはそれで詰みそう…。


あと、Scala側にあるTee.mergeOuterJoinってHaskell側にもあるのだろうか？
あるなら参考にできそうなのでちょっと探してみよう。

【2013/03/18追記】
@xuwei-kさんのわかりやすい型講座により把握できました。ありがとうございます！

scala-machines Tee.left

というわけで

地道に現実を知りながら育てていく予定です。


少し話がそれるけれど、こういう感じにコードを書きなぐっているとMachinesハッカソンがやりたくなってくる。

東京で開催できないですかね？
会場をみつけることができればいいのかな…時期はいつでもいいわけだし。
machinesに何かしら思うところがある型は反応していただければ…。

*1:私がへなちょこなだけかもしれないが…

Groovy基礎勉強会とNagoya.Testing in Tokyo3に潜入してました

イベント

主催者のきょんさんに「Groovy基礎勉強会で発表よろしく！」とお誘いをうけたので喋ってきました。
あと、翌日はNagoya.Testingを開催するとのことだったのでお手伝いとして参加しました。

2013/03/09(#GroovyBase)Groovy基礎勉強会 - Togetterまとめ

ことりちゃんがみえたあたりからが私のセッションのようです。

資料など

GParsのActor Modelとか言っておきながらひたすらActor Modelについて喋ってました。
素人知識なので間違いなどあれば指摘していただければ幸いです。

  • 最初にActor Modelがどのような形で応用されている（使われている）のか話せばよかったかも？
  • 公理的操作群ではなく操作的意味論のほうがよかったのかな？
  • 一部、並行と並列を書き間違えていたことに本気で焦った
  • 資料の字が小さかったようで、すみません・・・今後はあらかじめ資料をupするか文字サイズ調整します

理論はからきしな私ですが、たまにはこういう内容を学んで発表するのもアリかなと思ったりおもわなかったりしますね。

ただ、"きょんさんの開催する基礎勉強会"だから問題なかった(?)ものの、他のところで話す場合は前提となる用語の説明とか、実装よりの話を多く入れるべきなのでしょうね。


Groovy基礎勉強会に関しては「やっぱりASTな話が多いのねー」という感じでした。

抽象構文木といえば、コンパイラの学習も再開したい…

『アジャイル開発とスクラム』と『SCRUM BOOT CAMP THE BOOK』を読んだ

書籍

久々の、そしておそらく学生生活最後の読書感想文です。

今回は今年1月、2月に発売されたスクラム系の本2冊。

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

最初は別々に記事を書こうと思っていたのですが、書けるときに書いておかないと両方書きそうにないので、まとめてしましました…。

購入理由

前者は『ユーザー向け』というのに興味をもったからで、後者は

感じたことをざっくりまとめると

アジャイル開発とスクラムが経営層・プロダクトオーナー対象、SCRUMBC本がスクラムマスター対象かな、という印象を受けました。
アジャイルサムライ*1などは開発チームを対象にしている印象があるので、三点セットで読めばアジャイルやスクラムを学べるのではないでしょうか。

スクラムを通して考える

アジャイル開発とスクラムでは、ソフトウェア開発におけるリーダーシップと企業理念・イノベーションについて、スクラムを通して考えることになります。

SCRUM BOOT CAMP THE BOOKでは、スクラムを通して"学びの仕組み"について考えることができます。

雑感

SCRUMBC本にはプラクティスという言葉がほとんど（もしくは全く？）出てこない。TDDやペアプロなどの言葉も登場はするものの、言葉の説明はない。"Scrum Boot Camp"の本だからなのかはわからないですが、この割り切り(?)方は好きです。

対して、アジャイル開発とスクラムにはプラクティスが概説されています。こちらは"ユーザー向け"だからこそ説明を入れたのでしょうか。

そう考えると、この2冊(サムライ入れると3冊か)は絶妙なバランスですね。

気になったところ

SCRUMBC本、p109。

ボク「1週間で8ポイント…全部で168ポイントだから…」
ボク「今の人数で5ヶ月あれば…イケる！」
ボク「ブチョーと営業部長のところに行ってくる！」
キミ「いってらっしゃい…って、なんなの…」

SCRUM BOOT CAMP THE BOOK

仮に1ヶ月=4週間計算だったとして、5ヶ月で160が限界なのではー、と思った*2のはさておき。
これ、どう説明したのだろうね…というところが気になっていたりします。

おわりに

各視点から考えてみたい、学びたい方にもお勧めです。

アジャイル開発とスクラム、SCRUM BOOT CAMP THE BOOKは読書速度の早い方なら土日で読みきれると思います。わりと遅めの私でも前者は3日、後者に至っては1日かからなかったので。ちなみに、アジャイルサムライも3日くらいあればたぶん読めるので、読書の苦手な方にも大変親切な3冊ですね。


最後に。この文章は実践が伴っていない感想なので、仕事でScrumチームに入る日が来れば、改めてもう一度読み直して感想を書こうと思います。

*1:スクラムの本ではないけれど…

*2:前ページに「次のプロジェクトが半年後から始まる」と書かれているので、もしかしてそこから「リミット半年->168ポイントは大丈夫」だと判断した…？

今年はじめのTDDBC大阪(通称3.0)を開催しました

イベント TDD F#

1/12に2013年はじめのTDD Boot Camp in 大阪を、1/13に2013年はじめのTDD Boot Camp in 大阪 外伝を開催しました。

色々と書きたいことはあるのですが現在進行形で修論の理に導かれているので、空き時間に随時更新していきます。

謝辞

  • 会場スポンサーの株式会社Aiming様、および会場スタッフとしてお手伝いいただいたAiming社員さん
  • 講演もしくはディスカッションに登壇していただいた和田さん、渡辺さん、西さん、いろふさん
  • 当日スタッフおよびTAな方々
  • TDDBCのMLで意見を投げてくださった皆様
  • 本イベントに参加された皆様

ありがとうございました。
誰かが欠けても、本イベントは開催できなかったと、振り返ってみて改めて感じます。

開催理由

一部禁則事項に触れてしまうためすべては書けませんが、年始めにどでかい花火を打ち上げたかったとかそういうわけではないはずです。

一日目

いつもの内容で構成しました。

ペアプロの相方PC環境で苦労する問題はどうにかならないかなと思いつつ、今のところ初日にSCMBCを開催するしか思いついていないのが現状です。
何かないですかねぇ…。

二日目

当初はレガシーコード改善がいいなと思っていましたが、MLで「TDDBCで魂を削る必要は無い」という意見をいただいたため、最終的に「他人のコードを引き継ぐ」に変更しました。

イベントのゴールをもっと明確にすること、課題の難易度をもう少しゆるくすることが次回開催時に気をつけたいところでしょうか。

  • 【教訓】誕生日にイベントを開催すると心に深いダメージがある
  • その他2つの案「Test Double」と「リファクタリング」はAdvanced TDDBC的な感じでやってみたい

あとはこの大量のKPTをみると大体のことは察せると思われます。

TDD Boot Camp(TDDBC) - TDDBC大阪3.0/KPT

雑感

そういえば、今のTDDBCとかつてのTDDBCでは雰囲気全然違うなーとか思ったりします。
どっちが良い・悪いとかそういう意味ではありませんが、なんとなくそう感じます。

あと「手を挙げれば誰でも始められる」という言葉がかつてはありましたが、今はどうなのだろうと開催中に思ったりしたのでした。


あー、もう一つ。
全工程終了後のスタッフ振り返りはスタッフオンリーでやるべきだと反省しました。
コンテキスト共有が難しいのですよね…。

おまけ

F#でやってみていましたが、私の残念加減が露呈しただけでした。とりあえず残骸を晒しておくのでどなたか改善してくだしあ。

https://gist.github.com/4605144

副作用を持たない自動販売機とは。

おわりに

終わりは始まりのための終わりなのだよ、とよくわからない言葉で締めておきます。

関数型言語を独学で勉強している学生です に対する私的考え

その他

http://oshiete.goo.ne.jp/qa/7896221.html がTLで流れてきて、ちょっと思うところがあったので書きなぐっておきます。

なお、先に下記記事を読むことをおすすめします。丁寧かつとても面白い内容でした。

関数型言語を独学で勉強している学生です への答 - Oh, you `re no (fun _ → more)

これを読んで、自分でも少し言語化しておきたいと思いました。なので、投稿されていた質問に対する、昨年就活をしていた私個人の考えというか感想っぽい何かを簡単に書いておきます。

関数型言語で何か作って、それが新卒採用で評価されることはあるのか

あります。
私はいわゆる関数型言語の一つと言われているF#のコードを提出して、内定を頂きました。なので、技術を重視する会社であれば少なくとも可能性はあると思います。"可能性がある"と書いたのは、おそらく採用というのはコードだけで判断されるわけではないはずだからです。
ただまぁ、ほとんどの会社が"個人作成のオリジナル品"を要求するでしょうし（そうでないならコード要求しないと思います）、提示された条件をクリアしたコードである必要はありますよね、と。

いくつかの言語を試したほうがいいかも

（定義は人それぞれですが）関数型言語といってもたくさんあるので、納得がいくまで色んな関数型言語を触ってみるといいのでは、と思いました。そして、実用的なものがかけた言語でコード提出してみると。
これは時間の許す限りでしか行えない方法なので、時間のない場合は触ったことのある言語でやるしかないでしょうけれども…。

なぜ関数型言語のコードを提出したいのか

仕事で使いたいから、関数型言語に多少でも興味を持っている会社に就職したいから、自分の書いたコードが関数型言語のものしかないから…理由は様々あると思います。
いずれにせよ、何かしら肯定的な考えを持っていない限りは、無理してまで関数型言語で作ったものを提出しないほうがいいと思います…ってこれは書かなくてもわかることかもしれませんが。

何を作る？

別の言語で実装したものを移植してみる、とかでもアリなのではないでしょうか。車輪の再発明にはなりますが、まったく新しいものを作ろうとして挫折するよりは気が楽かなと。


以上、なげっぱなし記事でした。