Scala の Macro について

akihiro @akihiro4chawon

@kmizu どう書くべきかという問題提起した覚えは全くないですよ。再利用云々以前に、ミーハー的に新機能を試そうとしてファイルやプロジェクトを分けるのが若干メンドーと感じたという感想です。

akihiro @akihiro4chawon

dis っぽく感じた人がいるかもしれないので「そういう意図じゃないですよ」と言っておきますね。念のため＾＾

akihiro @akihiro4chawon

気軽に試せる環境が欲しいというのは素直なところ。Groovy の AST 変換は試す気になっても、scala のコンパイラプラグインは書く気にならなかった。（これをもって優劣を論じているんではないです。単純に試しやすいのはうれしいなという感じです）

Kenji Yoshida @xuwei_k

同じ(ファイルorクラス)内にあるマクロを呼び出してなければ、技術的には頑張ればコンパイラが自動で依存関係を解析してゴニョゴニョすればできそうだけれど、Nemerleに影響受けてて、Nemerleにも同じような制限があるなら、最終的にもコンパイル単位の制限はこのままなのかなたぶん

kmizu @kmizu

@akihiro4chawon いや、どう書くべきか、という問題提起と感じたわけではなくて、なんで(マクロを)同じ翻訳単位に書けない制約を付けるか、という事に関して認識のずれがあるように感じた、という話です。

akihiro @akihiro4chawon

@kmizu そうでしたか。認識のズレというのは、実装する側から見ての話でしょうか（制約を設けることで、実装簡易でパス数やコンパイル速度面で有利など？）、それともユーザ側にメリットがあるというお話でしょうか？普通にユーザなので使いやすければ使いやすいほど嬉しいという認識です。

kmizu @kmizu

@akihiro4chawon (マクロを呼び出す)ユーザにとってメリットがあるだろう、という話です(正式リリースされてないので、断言はできませんが)。マクロ定義が分割コンパイルされるようにすることで、たとえ(cont) http://t.co/fJ0JytCJ

kmizu @kmizu

@akihiro4chawon 特に、Scalaの場合、ライブラリはバイナリ(jar)で配付されるのが普通ですから、ソース形式でマクロライブラリを配付しなければいけない、となったらユーザにとっては凄く嫌じゃな(cont) http://t.co/kZ3RTnK3

akihiro @akihiro4chawon

@kmizu それは「分割コンパイルができない」処理系に対する比較優位です。分割も同一もOKな処理系に対するメリットではないように思います。

akihiro @akihiro4chawon

@kmizu それは、スタンダード化されたバイトコードが存在するか否かの問題ですね。ご指摘の通り、この点では、Haskell より scala のほうがよいと思います。（オープンソース原理主義者からみれば、とか妙な屁理屈を抜きにすれば（笑）

Kenji Yoshida @xuwei_k

Template Haskell 全然知らないので議論に混ざれない的な(´・ω・｀)

akihiro @akihiro4chawon

Lisp とかはどんな感じなんでしょうね。On Lisp や Let over Lambda に応用例が詳しく書いてあるのかな？

Kenji Yoshida @xuwei_k

OnLisp も Let over Lambda も持ってて読んだけど、だいぶ前なので全然忘れてるな・・・

kmizu @kmizu

@akihiro4chawon どうでしょうか。分割も同一もＯＫだとした場合、マクロに関するセマンティクスは、普通に考えてややこしくなりますから、ユーザにとってデメリットも(逆にメリットも)あるように思います(cont) http://t.co/IAyGef0X

kmizu @kmizu

@akihiro4chawon あと、実装の観点から言ってもマクロ定義と利用の分割を強制する事には一定のメリットがあります。たとえば、Scala Macro(およびその原型たるNemerle Macro)では(cont) http://t.co/x8GqZDyW

kmizu @kmizu

マクロ定義を呼び出しと別のコンパイル単位に定義しなければいけない、という制約がある事によるメリットは http://t.co/viZxSUIY の 9.4 Separate(cont) http://t.co/24wwH2sl

kmizu @kmizu

@xuwei_k はい。おっしゃるように、テクニカルには撤廃可能な制限かとは思います。ただ、その制限を回避するための実装努力に見合うだけのメリットがあるのか個人的には疑問に思いますです。Nemerle作った人は、この制限にはマクロの振る舞いが理解しやすくなるとかいくつも

kmizu @kmizu

@xuwei_k メリットがあるとか、 "Metaprogramming in Nemerle"で主張してました。あと、個人的にマクロシステムある言語作った経験から言っても、同じ翻訳単位にマクロ書けるようにするとやっぱり色々複雑化するなあとは思います。

shelarcy（しぇらーしぃ） @shelarcy

@kmizu @xuwei_k 同じファイル内にあるマクロを呼び出してなければ……というのは、まさに Template Haskell の制限ですね。 http://t.co/R5PXXYXl

shelarcy（しぇらーしぃ） @shelarcy

@kmizu @xuwei_k .｡oO(正確には、同じ相互再帰グループに属しているモジュールのマクロを呼び出していない場合ですが。)