ドイツ人数学者、Gottlob Frege氏から名付けられたFregeは、JVMのための純粋関数型の強力な型付き言語だ。FregeはHaskellと似ていて、「もっともHaskellらしいコードを修正せずに、または、見て分かる最小限の調整だけで動かせる。」

Fregeの開発者たちによると、Fregeは「パワー、単純さ、表現力の豊かさの組み合わせにおいて、類を見ないもの」である型システムをJVMに持ち込んだ。これにより、非正格 評価と型推論をサポートし、純粋性とデフォルトの不変性を可能にする。そのため、副作用は宣言された時のみ使うことができる。Fregeは、以下のようなHaskellの機能をほぼサポートしている。

ADTとパラメトリックポリモフィズムを用いた型クラス

より高いランクの型

パターンマッチング

リストの包含

do表記

ポイントフリースタイル

モジュール

functor、monoid、semigroup、monadなどの数学的な抽象

Fregeの重要な利点はJava相互運用性であり、Javaライブラリを再利用したり、JavaからFregeのコードを呼び出したりできる。FregeはJavaを呼ぶときに特に厳密であり、プログラマはFrege用語でJavaの型を宣言しなければならない。これにより、型システムの健全さを保ち、純粋性、スレッドの安全性、遅延を実施する。

JVMでFregeを利用できることで、大抵のJavaプロジェクトは、Haskellのパワーを使って、特定の問題を解決できる。

これは、標準出力で現在時刻を表示するFregeプログラムの例だ。

module examples.CommandLineClock where data Date = native java.util.Date where native new :: () -> IO (MutableIO Date) -- new Date() native toString :: Mutable s Date -> ST s String -- d.toString() --- 'IO' action to give us the current time as 'String' current :: IO String current = do d <- Date.new () -- reads system timer, hence IO d.toString main args = forever do current >>= print -- print formatted date print "\r" -- followed by carriage return stdout.flush -- make sure it's shown Thread.sleep 999L -- wait 0.999 seconds

Fregeコンパイラ、標準ライブラリ、REPL、その他のツールは、すべてFregeで書かれており、言語の安定性と完全性を証明している。

Fregeには、機能を試せるオンラインREPLがある。

InfoQは、Fregeの作者であるIngo Wechsung氏に話を聞いた。

Fregeの歴史を詳しく教えてください。Fregeはどのように生まれ、進化したのですか?

Fregeは、実は単なる偶然で生まれました。2003/2004年頃、メーリングリストで型推論について書かれたブログを読みました。私はすっかり魅了され、当時は黒魔術のように見えていたことを理解しようとしました。結局、私は、Simon Peyton-Jones氏によって書かれた論文をどうにかこうにか読みました。彼は、Haskellの共同発明者であり、GHC(Glasgow Haskell Compiler)の作者、また、今でも主にメンテナンスをしています。その論文は、「より高いランクの型のための実際的な型推論」について書かれていて、Haskellの型チェッカーの実装例を含んでいました。しかし、その当時、私が好きだった言語はPerlで、Haskellはまったく理解していませんでした。そこで、私は、型推論を本当に理解するために、Perlで型推論のアルゴリズムを実装することにしました。これは、かなりうまくいきましたが、型チェッカーが動いた“コード”は、Perlでエンコードされた、甘ったるいラムダ計算論法を表したものでした。(今は“埋め込み式DSL”と言うでしょう。) 私は、いつもパーサのようなものを書くのを楽しんでいたので、テキストファイルから式を読むフロントエンドを追加しました。一度、これがうまくいくと、型チェックした式をPerlのコードに変換することもできると考えました。これはうまくいきましたが、みじめなほど遅かったのです。セルフホスティングコンパイラなんていらないと思いました。それがFrege 1でした。 Perlはこのビジネスで使うには遅すぎるとわかったので、もっと速いホスト言語を探しました。私は、PASCAL、C、C++といくつかのスクリプト言語を自由に使えましたが、Cを出力するHaskellコンパイラはすでに存在していて、そこでは何も新しいことがありませんでした。だから、Cを使わないことに決めました。その時、私はJavaを習ったことがなかったので、Javaの練習プロジェクトにしない手はありません。多くのプログラマと同様、私はやりながら覚えたほうがよいのです。 2006年の終わりと2007年の初めに、私は、Javaをホスト言語としてFrege 2を作り始めました。そして、作りながら沢山のことを学びました。残念なことに、私はコンパイルする言語について明確なアイディアを持っていませんでした。それは、私が手に入れられるものはなんでも読んだにもかかわらず、関数型プログラミングに関して十分学べなかったからです。信じられないかもしれませんが、当時はそのような状況でした。幸いにも、ほんの少し名前を挙げれば、Simon Peyton-Jones氏、Phil Wadler氏、Paul Hudak氏等が、大抵は学術的な論文でしたが、数多く発表していました。これらの論文は理解するのが難しい部分があり、私は、しばしば悪戦苦闘しました。 特に、私はモナドをなかなか理解できませんでした。本職の数学者、ただし、研究分野は整数論である私の父に質問しさえしました。モナドに関するWikiの記事を探し出し、父に説明してくれるように頼みました。父はその記事を読んで、「確かに、この記事はとてもよい内容だ。対象、変換、同形、同一性がある。これは全部、本当に簡単なことだ。何が理解できない? 結局、ここから何を知りたいんだ? 」これが、私が持った疑問そのものでした。どうして私は、プログラマとして、モナドについて知らなければならないのでしょうか? それにもかかわらず、私はセルフホスティングのフランケンシュタインのような言語をどうにかこうにか作りました。それがFrege 2でした。明確な意味論もなく、純正でもなく、lazyでもstrictでもありませんでした。そして、whileループまでありました。めちゃくちゃでしたが、動きました。純正、普遍性、構成可能性について、私はいくつかのことを学びました。私は全部不満に思い、Frege2で、Frege2のコンパイラを書く過程において、自分のアプローチに欠陥があることを次第にはっきりと理解するようになりました。 この頃、私はfregepl.blogspot.comでブログを始めました。このプログでは、2007以降の当時の私の苦労が見られるオリジナルの投稿が読めます。 2008/2009年は、ほとんど進みませんでした。個人的な出来事があり、さらに、引っ越したので、プログラミングをする代わりに、壁を塗ったり、他のことをしたりするのに忙しかったのです。 Frege 2の経験から、私はやっと言語全体を見直すことができました。この時、私は明確なゴール、Haskell 98 (のちのHaskell 2010)がありました。このゴールは、2011年5月に大体達成でき、code.google.comでFregeをリリースしました。その後、Google Codeが衰退し始めたので、GitHubに移りました。 翌年、Fregeのあらゆる種類のバグを修正し、Eclipseプラグインを開発するのに忙しくなりました。 その間に、初期導入者たちはFregeの存在に気付きました。ここでは、Yorrik Laupa氏とDaniel Gronau氏の名前を挙げましょう。彼らは、「カテゴリ理論」型クラスのApplicative、Monad等の様々なレイアウトを採用するように私に勧め、それらを実装してくれました。 (この“Applicative-Monad”構造は、何年もの間、Haskellコミュニティで提案されていましたが、最近GHCで採用されただけでした。) その少しだけ後に、New Yorkからインディアンの伝統を引き継ぐプログラマ、Marimuthu Madasamy氏が実装に参加し始めました。Madasamy氏は、Frege REPLの作者です。Frege REPLはオンラインバージョンにあり、スタンドアロンアプリケーションとして、ローカルで使えます。また、彼はJSR 223のスクリプトをサポートし、JavaからFregeスクリプトを実行できるようにしました。何年もの間、彼は、堅実で情熱的な努力によって、Fregeにとても沢山のことをしてくれました。悲しいことに、私たちは現実世界でお互いに会ったことがありません。私はこの人をハグしたいと心から思っています! James Earl Douglas氏とMark Derricut氏はウェブページ、SBT、Maven Supportを担当し、FregeがOSGiに準拠しているか確認しました。その後、Sean Corfield氏が、Fregeと動くClojure leinツールを可能にするプラグインを作成しました。そして、Mark Perry氏は、gradleで同様のことを行い、Groovyビルドツールを作成しました。(そのため、当時、Fregeには、実に4つのビルドツールがありました!) Fregeが人気になった最大の勝因は、間違いなくDierk König氏とのコラボレーションです。König氏は、彼の著書“Groovy in Action”によって、Groovyの世界で有名であり、純粋な機能原則の、思慮深く見識のある提唱者、そして、同時に、JVMエコシステムのエクスパートです。König氏は、あちこち旅して周り、カンファレンスでFregeについて話すのに忙しく、ブログにも投稿し、最後に一番大切なのは、Frege REPLのJavaFXバージョンに貢献したことです。

Fregeの成熟度は? Fregeを利用しているプロジェクトを知っていますか?

最初に、私が知る限り、Fregeを利用している商業的なプロジェクトはありません。しかし、教育分野では活動が見られます。例えば、FregeやFregeを使ったことについて、修士論文を書いている人たちがいます。 成熟度は両刃の剣です。言語自体とコンパイラはかなり安定し、強固だと主張できますが、モジュールリポジトリ等の付随するインフラストラクチャと共に、多くの作業が必要なライブラリです。一方で、抜きん出たHaskellライブラリのポート、もう一方では、重要なJVMライブラリを完成させ、テストし、ドキュメント化して利用できるようにしなければなりません。完成品に興味があり貢献したい人を歓迎することを宣伝するのに、ここはおそらくよい場所でしょう。新参者も含まれます! 国籍、人種、宗教、性別、年齢、その他プログラミングと関係のないことは聞かないことは言うまでもありません。今や、Fregeコミュニティは、非常に小さなものですが、様々な民族がいて、国際的だと言えることを私は誇りに思います。Fregeの地で日が落ちることはありません!

Haskellとの機能差をなくす予定ですか? Fregeのロードマップには何がありますか?