expanderのimportは実はincludeと変わらない

[chaemon]

現状ではexpanderはそのまま展開するので、ローカル変数に同名の変数やobjectが別のファイルにあるとエラーが起こるかと思います。したがって、ローカル変数のimportは全体に公開されないようにしたいと思っていました。つまり、expanderで書いたimportは事実上includeになっています。

前にzer0starさんがblockを使った方式を提案していただきましたが、expanderが関数名を全部把握しなくてはならない点や同名で引数だけが違う関数が使えないといった問題がありました。

これについていろいろ調べてみたところ、genSym, injectプラグマを利用してtemplateの形で展開すると良さそうだということがわかりました。現状、ローカル変数のバッティングがあまり起こらないので、expanderにわざわざその機能を入れる必要があるかというところではあります。

[chaemon]

つまり、expanderの方式をこれにすると、すべてのライブラリで以下の変更が必要になります。

• 変数・objectはデフォルトがgenSymで公開されないため、外に公開したい変数・objectすべてにgenSymをつける必要がある
• 関数(proc)はデフォルトがinjectで公開されるため、外に公開したくない関数(proc)すべてにinjectをつける必要がある

[zer0-star]

確かに、templateだと疑似的に名前空間のようなものを作れるのは良いかもしれませんね。とはいえ、大きな変更となるのでどうするか難しいところです。

[chaemon]

そうなんです。。。そもそもモジュール内にオブジェクトを隠したい場面があまり思いつかない割に、この変更を行うと既存のコードにinjectやgenSymをつけなくてはならなくなってしまうので、今の所必要ないかなーと思っています。

あるいは*がついたobject・変数に自動でinjectをつけて、*がついていないprocに自動でgenSymをつけるマクロを作りexpanderの中でそれが呼ばれるようにすれば自動で対応可能ではありますね。

[chaemon]

ところで、最近気づいたのですが、atcoderではコンパイル時にファイルを生成してそれをimportするみたいなことができちゃうようですねー

[zer0-star]

それ、めちゃくちゃ凄いですね......使えるかもしれません

[chaemon]

そうなんです！それ以外に、zip等のlinuxコマンドも呼び出せるので、さっそくNim-ACLを圧縮して送信し、それを展開して実行するexpanderの機能を作りました。こちらのように、staticExecで外部プログラムを呼び出しています

https://atcoder.jp/contests/abc263/submissions/33867525

[chaemon]

こんな感じに、コンパイル時にstaticExecでソースに圧縮して仕込んでおいたファイルを展開してatcoderというディレクトリを作って、そのディレクトリをそのままimportできました。

https://atcoder.jp/contests/abc256/submissions/33885705

提出の9, 10行目がNim-ACLの内容を展開してディレクトリを作成する処理をやっていて、以降import atcoder/*系の命令ができるようになっています。

問題はコンパイル時にインクルードパスが指定できないため、Main.nimがimport atcoder/hogeでhogeをimportしていて、import先のhoge.nimがatcoder/barをimportしている場合、hogeからatcoder/barが認識できないという問題があります。

今はexpanderでimportを絶対パスに書き換える操作を行っています。書き換えないでそのまま必要なソースだけコピーして固めるようにできるとなおよいです。