DLR ASTを使っただけの言語と、DLRな言語は違うんじゃないか、と思ったしだいである
みんながオレ言語をつくるようになったのはすごくいいことなんだけど。
DLRは言語共通のプラットフォームになる方面にも向いていて、その仕組みもMicrosoft.Scripting.dllには入っている。うえのサイトのサンプル言語はその面をばっさり切り捨てて、単にDLR Ast(のC#構文相当のAST)を使ってソースコード→アセンブリに変換するCLRセマンティクスの言語になってる。
ソースにはコメントアウトされた部分があって、それはDLRセマンティク→CLRセマンティクス変換を行うべきパートであるので、サイトの作者自身はあるていどはわかってるんだとは思うけど、そこを書いてないのはよくないと思う。
具体的にいえば、DLRの6タイプのActionにオブジェクトセマンティクスを規定している。ActionはAssembly上のDLRオブジェクトの操作のためのバイトコードを表現するためにある。で、Action実行時は、DLRのオブジェクトにたいし、各言語のActionBinderで定義する、その言語のDLRオブジェクトのActionのCLRレベルでのセマンティクスを具体的に行うコードを作るStandardRuleが取り出され、（コードはキャッシュされつつ）それが実行されるようになってる。
つまり、DLRな言語であれば、あらゆるオブジェクトアクセスは必ずActionを呼び出す形式のAstに変換されなくてはいけない、はず。IDynamicObjectがRuleを取り出せるだけになってるのは、そのオブジェクトを別のDLR言語で処理できるようにするため。別の言語でもオブジェクトはActionを呼ぶというスタイルでアセンブリが作られる。だから、他のDLR言語で作られた自分はその仕組みをよく知らないオブジェクト(IDynamicObject)でも、きちんと実行できる。
Pythonでfoo()ってなってたら、パーズしたあとのDLR AST上はCallActionを呼ぶものになる。それが実行時はC#でつくったdelegateだろうが、Python上でdefで作ったものだろうが、Ruby上で作ったblockであろうが。
ここで「カスタムアクションを作る〜」って書いてるけど、それはいけないはず。独自のアクションはその言語しか使えないから。(AOPでも何でもいいけど)特殊なことをやるのなら、すべてのオブジェクト操作はCallかなにかのActionにマッピングする、もしくは言語自体からActionBinderをがりがりにカスタマイズできるようにする、かだろう。
