Lisp Meetup #30の発表資料です。

1. Clojureシンタックスハイライター
開発から考える
これからのLispに必要なもの
Lisp meet up #30
@athos0220

2. genuine-highlighter
‣ マクロを認識するシンタックス
ハイライター
‣ Clojureの細粒度解析器
symbol-analyzer上に実現
‣ 技術的な詳細はShibuya.lisp TT
#8を参照
lein-highlight
genuine-highlighter
symbol-analyzer

3. シンタックスハイライターから感じたこと
‣ 解析の精度を上げようとすればするほど、リーダやコン
パイラがやっていることの再実装をするハメに
‣ リーダやコンパイラ等、標準機能は再利用できなかった
‣ Lispはメタプログラミングに強い言語だったのでは…？

4. LispはLispコードを扱うのが得意

5. LispはLispコードを扱うのが得意

6. LispはLispコードを扱うのが得意
LispはS式を扱うのが得意

7. Lispの強力さの秘訣
ソースコード
マクロ
展開済みS式
S式
read
macro
expand compile

8. Lispの強力さの秘訣
ソースコード
マクロ
展開済みS式
S式
read
macro
expand compile
コンパイラが感知するのは
これ以降
最終的にコンパイラの知るフォームに落ちれば
マクロやリーダマクロで自由に拡張可能

9. Lispの強力さの秘訣
‣ Lispは「プログラマが実際にどういうコードを書いているのか」に
無頓着になることで強力な拡張性を得てきた
‣ そのことがコードの静的解析を難しくしている
ソースコード
マクロ
展開済みS式
S式
read
macro
expand compile
コンパイラが感知するのは
これ以降
最終的にコンパイラの知るフォームに落ちれば
マクロやリーダマクロで自由に拡張可能

10. Clojure界隈での事情
‣ コード解析が不完全なツールたち
• Kibit: コーディングチェッカ
• bikeshed: コーディングチェッカ
• Yagni: コールグラフ解析ツール
• cloverage: カバレッジツール
• clojail: サンドボックスツール
• etc. etc.
‣ tools.analyzerの登場により、状況はある程度改善したが
tools.analyzerを使っても不十分なケースも少なくない

11. コードの“読み手”
プログラマ 処理系コード

12. コードの“読み手”
カバレッジツールコードフォーマッタ
IDE・エディタ メトリクス計測ツール
プログラマ 処理系
コーディングチェッカ
コード

13. コードの“読み手”
‣ プログラマと処理系だけがコードを読む牧歌的な時代は終わり、
今や多くのCASE ツールがコードを読む時代
‣ これらのツールの多くが知りたいのは「プログラマがどういう
コードを書いたか」≠ コンパイラにどんなコードが渡るか
*1
カバレッジツールコードフォーマッタ
IDE・エディタ メトリクス計測ツール
プログラマ 処理系
コーディングチェッカ
*1 CASE: Computer-Aided Software Engineering,
一般にはもっと高機能なものを指すが、ここでは「コードを解析するツール」程度の意味。
コード

14. グリーンスパンの第10法則

15. グリーンスパンの第10法則
十分に複雑なCまたはFortranのプログラムは全て、後付けで
正式な仕様がなく、バグがてんこもりの遅いCommon Lisp
の半分の実装を含んでいる
“

16. グリーンスパンの第10法則
十分に複雑なCまたはFortranのプログラムは全て、後付けで
正式な仕様がなく、バグがてんこもりの遅いCommon Lisp
の半分の実装を含んでいる
“
十分に複雑なLispのコード解析器は全て、後付けで正式な仕
様がなく、バグがてんこもりの遅いLispの半分の実装を含ん
でいる…？

17. グリーンスパンの第10法則
‣ LisperもまたLispを(ムダに)再実装している
‣ 共通で使える汎用的なしくみは用意できないのか？
十分に複雑なCまたはFortranのプログラムは全て、後付けで
正式な仕様がなく、バグがてんこもりの遅いCommon Lisp
の半分の実装を含んでいる
“
十分に複雑なLispのコード解析器は全て、後付けで正式な仕
様がなく、バグがてんこもりの遅いLispの半分の実装を含ん
でいる…？

18. JavaScriptの場合…
‣ Esprima：汎用的なJSコード解析器
‣ 多くのJS CASEツールがEsprima上に実装されている
‣ Lispの場合はマクロがあるので、問題はこんなに簡単で
はない(が目指す状況はこんな感じ)

19. 処理系ごとの対応
‣ コード解析は処理系におまかせ、という手もある？
• (例)いくつかのCL処理系は独自にテストカバレッジ機能を提供
• 他の機能についても処理系の対応を待つ…？
‣ 言語機能自体はマクロで拡張できるのに、コード解析に
ついては処理系の対応待ちが必要というのは歯がゆい

20. では、どうするか？
‣ 標準化
• Schemeのシンタックスオブジェクト的な方向性はよさそう
• Common Clojure Source Metadata Model
‣ 汎用的なコード解析器
‣ 解析器が解析しやすいコードをプログラマが書く
• スタイルだけで解決できる問題か？
• 解析しやすいようにアノテーションをつける？
‣ etc.

21. まとめ
‣ コードをプログラマと処理系だけが読めればいい時代は
すでに終わり
‣ CASEツールの解析で必要なのは「プログラマがどうい
うコードを書いたか」
‣ マクロがあることを口実にまともにコード解析できない
現状から逃げ続けていいのか？