Kouhei Sutou
kou****@clear*****
2014年 1月 20日 (月) 16:18:42 JST
須藤です。 In <52D85****@gmail*****> "[groonga-dev,02062] Haskell版C APIバインディングを作成しました その２" on Fri, 17 Jan 2014 06:42:38 +0900, hiroshi hatake <cosmo****@gmail*****> wrote: >>> > "Groonga"への表記統一の作業をしているうちに >>> > Groongaのバインディングを作ってみたら面白そうだと思い立ちました。 >> ありがとうございます！とても助かっています！ > おぉ、そう言って頂けるとありがたいです。そろそろ残り箇所が少なくなってき > たかなと思います。（が、そうでもないんでしょうか…。） 林さんが言っている通り、残り少なくなってきました！ ありがとうございます！ > じつはHaskellには何個かFFIを使ったライブラリの作り方があるんですよ。 おぉ。 > Haskellは実に様々な選択肢を提供します。 > ひとつはRuby-GNOME2のように人力でコードを書く方法です。 あぁ、これもできるんですね。 どんな感じで書くのかなぁと思って、ghc -Cしてみたら、Debian GNU/LinuxのGHCのビルド方法では.hsから.cの変換は無効になって いるみたいでした。残念。 （--enable-unregisterisedでビルドしてないといけなそう。） % ghc -C M.hs on the commandline: Warning: Compiler not unregisterised, so ignoring -C > 次はc2hsで書く方法です。 > http://www.skybluetrades.net/blog/posts/2013/09/22/c2hs-and-haskell-ffi.html > にありますが、これはどうやらC->Haskellへの変換ルールを書いてやるもののよ > うです。 なるほど、これは、独自言語なんですね。バインディングを作るた めの独自言語を使うというと、SWIGっぽいですね。SWIGはFFIを使う んじゃなくて、各言語が提供するバインディングを書くためのAPIを 使いますが。 って、あれ、各言語が提供するバインディングを書くためのAPIも FFIに含まれるんですか！？もしかして。 http://en.wikipedia.org/wiki/Foreign_function_interface In addition, many FFIs can be generated automatically: for example, SWIG. って、書いてますし。FFIってざっくりいうと、「Cのグルーコード を書かなくても他の言語のコードからCの関数を呼び出せるようにす るAPI」みたいに思っていて、各言語が提供するバインディングを 書くためのAPIはCのグルーコードを書かないといけないので違うの かと思っていました。 > 次はc2hsc+hsc2hsを使う方法です。 > これはHaroongaを書くのに使った方法で、Cから一旦hscという中間形式を経由し > てhsc2hsでHaskellのコードに変換してやる 方法です。この方法だと80%〜90%ほ > どの変換作業を自動化できます。 なるほど。 Cのソースをパースして中間形式にするなんて、GObject Introspectionみたいですね。 >> grn_obj->headerはリードオンリーで触ってもよいやつなんですが、 >> 低レベルの操作(*)をしなければ必要になることはないと思うので、 >> 大丈夫だと思います。 >> >> (*) （Groongaの世界の）オブジェクトの型によって処理を振り分けるとか > むむっ、C APIを使えばそこまで小回りが効くようになるんですね！ はい。 パトリシアトライのライブラリーとしてGroongaを使いたいとか、 転置インデックスのライブラリーとしてGroongaを使いたいとか、 でなければ必要にはならないと思います。 > そのうちHaroongaをどうやって作ったかについてブログに書こうとしているんで > すが、中々筆が進まなくて…。 そうこうしている間に書いていますね！ http://cosmo0920.wordpress.com/2014/01/18/groonga%E3%81%AEhaskell%E3%83%90%E3%82%A4%E3%83%B3%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%92%E6%9B%B8%E3%81%84%E3%81%9F%E3%80%82/ >> Simpleだと「どう使えるか」はわかるのですが、「何ができるのか」 >> はわかりずらいので、もしかしたら、Groonga.CommandAPIとか >> Groonga.QueryAPIとかにした方がよいかもしれませんね。 > そうですね！ありがとうございます。 > 仰る通り、Simpleだと確かにどう使えるかはわかるんですが、 > 何が出来るかが把握できないのでCommandAPIにしました！ 参考になったようでなによりです！ > また、もうすこしHaskellらしくするためにCommandAPIのAPIの関数の型を単なる > Stringではなく、Command型や Database型を関数の引数の型に使ってやることに > しました。ユーザー定義型が組み込み型に比べて少ない機能を提供するC系の言 > 語では出てこ ない発想だと思うので解説します。 あぁ、それはよいと思います。 実は、groonga-gobjectもcommand型を作ろうと思っていました。 文字列で渡すAPIはエスケープとか自分でやってね！というAPIで、 groonga実行コマンド相当のものを作るのに便利なやつ（ユーザー からの入力をそのままGroongaに渡せる）にして、 command型のやつは、構造化されたデータとしてGroongaにコマンド を渡せるAPIで、APIとしてGroongaのコマンドを実行するのに便利 なやつにしようと思っていました。 select = ggrn_command_new("select"); ggrn_command_add_arguments(select, "table", "Users", "match_columns", "description", "query", "groonga", NULL); ggrn_context_execute_command(context, select); みたいな感じのができるといいなぁと思っていました。 > そして、コンパイル時により高度な型チェックが出来るようになります。それを > 応用したものに、RubyでいうRailsのフレームワークの位置づ けにあるYesodと > いうフレームワークがあるんですが、それのDBのバックエンドにはPersistentと > いうフレームワークが使われていま す。 おぉ、Haskellにもそういうのがあるんですか。知りませんでした。 > なぜ、このような話をしたかというと、CommandAPIを選択してQueryAPIの名前を > 選択を選択肢なかったかの理由を述べるためです。 > QueryAPIというと、Relationを扱うという意味が入ってしまうかな、と思ったた > めです。更にいうと、コンパイル時のDSLを使って クエリーを生成するAPIか > な、と勘違いしそうだと思ったためです。 なるほど。Haskellだと、クエリーというとそういうイメージになっ ちゃうんですねぇ。 >> # groonga-gobject、リリースしないと。。。 > あらー、まだ未リリースだったんですね。 > 面白い試みだと思いますし、GObject-introspectionの仕組みを使っているGTK以 > 外では数少ないライブラリだと思うのでリ リースを楽しみにしてます！ （今月末に林さんがリリースしてくれそう。。。！） -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> (03-6231-7270) Groongaサポート: http://groonga.org/ja/support/ パッチ採用はじめました: http://www.clear-code.com/recruitment/ コミットへのコメントサービスはじめました: http://www.clear-code.com/services/commit-comment.html
