Vimの設定ファイル.vimrc, そしてVimのプラグインには, スクリプト言語Vim scriptが使用されます.
昨今の巨大なプラグイン製作者によるこの言語への不満が募り, 最近はVim scriptについて激しい議論が交わされています.
どんな言語か
静的型付け言語で, 命令形です.
while, if等基本的な制御文に加え, 関数もサポートされています.
変数の取り扱いが特徴的です.
オブジェクトがあるので, 苦し紛れにオブジェクト指向っぽく書くこともできます.
vim-jpで何が起こっているのか
Vim scriptを今後どうするかが話題になっています.
巨大なプラグインを書いていらっしゃる方々が, Vim scriptに不満をお持ちなのも当然だと思います.
一つは, 言語機能の問題.
無名関数が無く, 例えば組み込みのmapやfilterの引数はコード片の文字列です.
個人的には, 代数的データ型, 或いはstruct/enum相当がない(そもそも型がプリミティブしかない)事のほうが, 重大な気がします.
二つ目は, 速度の問題.
Vimのプラグインにさせたいことが多くなると, Vim scriptの速度の遅さが問題となります.
言語機能の問題はさておき, 速度の問題に対してはPythonに対してうん十倍から百倍近く遅いようで, 何とかしたいという気持ちはVimmerの共通認識としてあるようです.
Luaに変換して実行
一つの案として, Lua言語をVimにバンドルする案が出ています.
Vim scriptを読んだらそれをLuaに変換して実行しよう, 速度を気にするプラグイン開発者はLuaでプラグインを書こう, といった形だと思います.
Luaが選ばれたのは, 構文がVim scriptに近く, 実行速度が高速であるからのようです.
Vim scriptの実装をなんとかする
もう一つの案は, 実装を書き換えたらVim scriptの速度を速くできるのではというものです.
Vim scriptの実行には, 実行するたびにパースしており, 速度が遅いのはそれのせいであるというのです.
私の意見
まず, 私の意見は, 「なにも実装していないし根拠もないのにそんなこと言うなバカヤロー」と自分でも突っ込みたくなるレベルであり, 多くの憶測と偏見が入っていることをご了承ください.
しかもLuaのことを全く知りません(おい！！！).
その上で幾つか言わせていただきますと.
Luaに変換するプロジェクトには, 反対です.
反対と言いますか, 待った！です.
実装に関して, 様々な疑問が浮かんできます.
変数の扱いどうするの？ s: とか b: とかもあるよ？
エラーの扱いどうするの？ 元のスクリプトの行数とか変数名分かる？ Source Map？
Vim scriptの構文エラーって実行時エラーになるよね？ それどうする？
UIが絡むプログラムはどうするの？ LuaのソースをバンドルするときにVim側で実装されている関数を呼ぶ実装を織り込む？ ますますコードがファッキングにならない？
LuaのソースからVim側の変数テーブルにアクセスできるようにしなきゃいけない？ 遅くならない？
数字や文字は1:1で変換して大丈夫なの？ ほんとに？ バイト文字とかエンコーディング周りも大丈夫？
readonlyな変数はどうするの？ そういうものへの書き込みエラーをLua側で飛ばせる？
Luaのソースコードに手をいれる？ Luaのバージョン上がった時どうする？
変換できない関数は変換しない？ どういう基準か分からないけど, 既存のプラグインで書かれている関数のどれくらいが変換対象になるの？ それで全体がどれぐらい速くなるの？ それって結局Vim scriptのインタープリター改善したほうが良くね？
Lua, 意外と大きそうだけど, 本当にガッチャンコできるの？
適当にプラグインのコードを見てたら, executeとかmapとかfilterが結構あるけど大丈夫？
Luaが速いのは置いておいて, 変換は速くできるの？
他の言語をVimに取り込むのを理屈抜きに毛嫌いしそうな人もいそうじゃない？
...
ありとあらゆる問題を解決した上で, 完璧に変換できた時, そのLuaスクリプトは元のスクリプトの何十倍にもなるでしょう.
たとえLuaが速くても, 生成コードが大きかったら, Vim scriptのインタープリターを速くしたほうが, 結果がいいと思います.
Vim scriptのインタープリターの高速化
上記の疑問から, Luaへの変換は非現実的だろうと思うわけで, Vim scriptの実装を何とかして欲しいなぁと思うわけです.
あ, いや, 私はそこまでVim scriptの遅さが気になっているわけではないんですけどね(プラグイン開発者の皆様に感謝).
Vimのソースコードを落としてチラッと見てみたのですが, どうやらeval.cというものを読めば良さげです.
ただし, 最新のものは二万行以上あるので, アカンヤツや... となりました.
そこでVim 5.0のソースコードをみてみると, eval.cは2789行.
なんとかなりそう？ うっ...
こちらもかなり大きな作業になりそうですなぁ.
しかし, Luaに変換するよりは, 幾分現実的だと思います.
まぁあまり根拠はないんですけどね. 直感ですよ直感.
Luaに変換する話と, Vim scriptの実装を何とかする話は, 相対するものではありません.
いずれにせよ, 実装はなんとかしなければならないんです.
後者は, 誰かがやらなければならない.
三つ目の選択肢, 「何もしない, 現状に満足することにする」を選ばない限りは.
どちらも大きな作業になることが予想されるけれど, 前者の方が非現実的だろうと思うわけです.
ともかく
Luaに変換するプロジェクトは座礁すると思いますよ.
何らかの壁に阻まれて.
いや, 完遂したらほんと土下座して謝りますよ.
あの時はでしゃばってあんな事言ってすみませんでしたって.
凄腕のプログラマーさんたちが集まっていらっしゃいますからね, その可能性もあるかもしれません.
一番問題なのは, Vimmerたちが決裂してしまうことです.
色んな意味で, ですよ.
(やっぱC言語で書かれたVim scriptのパーサーが必要だよ！と思い, yacc+lexでゴニョゴニョしようとしたけど, 前に使ったのが二年前ですっかり忘れていて, 何もできずに2〜3時間で放り投げたのは, ここだけの話です.)
追記(2013/4/2)
反論頂きました.
Vim scriptを取り巻く問題など存在しない (領土問題風に) — KaoriYa
そうです, こういうのが読みたかったんですよ.
意外と完成形が見えてらっしゃる感じで, 安心した.
これまでのvim-jpのissueからはこういうのが全然読み取れなかった.
まぁこれで速くなるかどうかは未知数ですね.
それでもやっぱり, VimL高速インタープリター実装したダークホースが一年後くらいに突然現れてヒーローになる未来, 期待してる.
