タイトルのとおりです．
スライドは以下です．
もうちょい詳しく話す予定だったんですが，冒頭のライブリリースに失敗するなどして出鼻をくじかれテンパってしまいました……
ちょっと詳しい話をすると，
- ポリシー周り
- フィルターもゆるふわなインターフェイス的思想になってて，
filter()というメソッドを持ち，filterしたいポリシー名を含んだarray referenceを返す． - こんな感じで，新しいポリシーやフィルターを作りやすい！！ と思ってたんだけどそうでもない気がする，後述．
- とりあえず，開発のモチベーションとして，処理が高速でないと話にならんと思ったのでパフォーマンスの為にあえてダーティなコードを書いている部分がある
- 一方でパフォーマンスとは関係の無いダーティなコードも書いている
- あとまあ，Perl::Lintが速い場合と遅い場合があるのはわかっていて，スライドには割と恣意的なベンチの結果を載せている
あと，現状だと独自のポリシーとか独自のフィルターを書く為の敷居が高過ぎる (例えば，作法とかが一切わからん) という意見をもらったので，そこら辺を上手くサポート（チュートリアルとかスケルトンジェネレータとかで）したいなあというモチベーションになりました．何か良い意見あれば是非教えて下さい！
質疑応答は（覚えている限り）以下のとおりです．
Q. なんでAST使わないの？
A. Compiler::Parserがまだ不安定で，解釈できないコードが多かったため諦めた
Q. ASTじゃなくてToken使うことによるメリットってあるの？
A. よくわからない，無いのでは．手でToken走査して頑張るの本当に大変．ASTあるなら本当に使いたいケースは確かにある．
Q. Compiler::Lexer，SEGVとか多いイメージあるけど最近どう？
A. 最近では少なくなっているとは思います．でもまあ起きるには起きるんで……
Q. コントリビュータ募集って言ってたけど，どのへんに協力して欲しいの？
A. ぶっちゃけ僕が実装したくないポリシーを実装して欲しいんですけど，まあ無理な話なんでドキュメントとかで協力していただきたく存じます．
Q. Perl::LintにPerl::LintかけるとたくさんPerl::Lintのviolation出るけどこれって直るの？
A. 無理では……（ほんとうに難しい）
Q. C-Style forやめたら？
A. C-Style forの方が楽なんで許して欲しい (これは発表中にも喋ったんですけど，トークンの先読みとか後戻りとかを結構するので自在にインデックスをいじれたほうが良い)
YAPC会期中は常に会場のどこかしらにいますんで，何かPerl::Lint周りに興味がある方いらっしゃいましたらお話しましょう！
