Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Clojureシンタックスハイライター開発から考えるこれからのlispに必要なもの

6,412 views

Published on

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

Published in: Software
  • Be the first to comment

Clojureシンタックスハイライター開発から考えるこれからのlispに必要なもの

  1. 1. Clojureシンタックスハイライター 開発から考える これからのLispに必要なもの Lisp meet up #30 @athos0220
  2. 2. genuine-highlighter ‣ マクロを認識するシンタックス ハイライター ‣ Clojureの細粒度解析器  symbol-analyzer上に実現 ‣ 技術的な詳細はShibuya.lisp TT #8を参照 lein-highlight genuine-highlighter symbol-analyzer
  3. 3. シンタックスハイライターから感じたこと ‣ 解析の精度を上げようとすればするほど、リーダやコン パイラがやっていることの再実装をするハメに ‣ リーダやコンパイラ等、標準機能は再利用できなかった ‣ Lispはメタプログラミングに強い言語だったのでは…?
  4. 4. LispはLispコードを扱うのが得意
  5. 5. LispはLispコードを扱うのが得意
  6. 6. LispはLispコードを扱うのが得意 LispはS式を扱うのが得意
  7. 7. Lispの強力さの秘訣 ソースコード マクロ 展開済みS式 S式 read macro expand compile
  8. 8. Lispの強力さの秘訣 ソースコード マクロ 展開済みS式 S式 read macro expand compile コンパイラが感知するのは これ以降 最終的にコンパイラの知るフォームに落ちれば マクロやリーダマクロで自由に拡張可能
  9. 9. Lispの強力さの秘訣 ‣ Lispは「プログラマが実際にどういうコードを書いているのか」に 無頓着になることで強力な拡張性を得てきた ‣ そのことがコードの静的解析を難しくしている ソースコード マクロ 展開済みS式 S式 read macro expand compile コンパイラが感知するのは これ以降 最終的にコンパイラの知るフォームに落ちれば マクロやリーダマクロで自由に拡張可能
  10. 10. Clojure界隈での事情 ‣ コード解析が不完全なツールたち • Kibit: コーディングチェッカ • bikeshed: コーディングチェッカ • Yagni: コールグラフ解析ツール • cloverage: カバレッジツール • clojail: サンドボックスツール • etc. etc. ‣ tools.analyzerの登場により、状況はある程度改善したが tools.analyzerを使っても不十分なケースも少なくない
  11. 11. コードの“読み手” プログラマ 処理系コード
  12. 12. コードの“読み手” カバレッジツールコードフォーマッタ IDE・エディタ メトリクス計測ツール プログラマ 処理系 コーディングチェッカ コード
  13. 13. コードの“読み手” ‣ プログラマと処理系だけがコードを読む牧歌的な時代は終わり、 今や多くのCASE ツールがコードを読む時代 ‣ これらのツールの多くが知りたいのは「プログラマがどういう コードを書いたか」≠ コンパイラにどんなコードが渡るか *1 カバレッジツールコードフォーマッタ IDE・エディタ メトリクス計測ツール プログラマ 処理系 コーディングチェッカ *1 CASE: Computer-Aided Software Engineering,     一般にはもっと高機能なものを指すが、ここでは「コードを解析するツール」程度の意味。 コード
  14. 14. グリーンスパンの第10法則
  15. 15. グリーンスパンの第10法則 十分に複雑なCまたはFortranのプログラムは全て、後付けで 正式な仕様がなく、バグがてんこもりの遅いCommon Lisp の半分の実装を含んでいる “
  16. 16. グリーンスパンの第10法則 十分に複雑なCまたはFortranのプログラムは全て、後付けで 正式な仕様がなく、バグがてんこもりの遅いCommon Lisp の半分の実装を含んでいる “ 十分に複雑なLispのコード解析器は全て、後付けで正式な仕 様がなく、バグがてんこもりの遅いLispの半分の実装を含ん でいる…?
  17. 17. グリーンスパンの第10法則 ‣ LisperもまたLispを(ムダに)再実装している ‣ 共通で使える汎用的なしくみは用意できないのか? 十分に複雑なCまたはFortranのプログラムは全て、後付けで 正式な仕様がなく、バグがてんこもりの遅いCommon Lisp の半分の実装を含んでいる “ 十分に複雑なLispのコード解析器は全て、後付けで正式な仕 様がなく、バグがてんこもりの遅いLispの半分の実装を含ん でいる…?
  18. 18. JavaScriptの場合… ‣ Esprima:汎用的なJSコード解析器 ‣ 多くのJS CASEツールがEsprima上に実装されている ‣ Lispの場合はマクロがあるので、問題はこんなに簡単で はない(が目指す状況はこんな感じ)
  19. 19. 処理系ごとの対応 ‣ コード解析は処理系におまかせ、という手もある? • (例)いくつかのCL処理系は独自にテストカバレッジ機能を提供 • 他の機能についても処理系の対応を待つ…? ‣ 言語機能自体はマクロで拡張できるのに、コード解析に ついては処理系の対応待ちが必要というのは歯がゆい
  20. 20. では、どうするか? ‣ 標準化 • Schemeのシンタックスオブジェクト的な方向性はよさそう • Common Clojure Source Metadata Model ‣ 汎用的なコード解析器 ‣ 解析器が解析しやすいコードをプログラマが書く • スタイルだけで解決できる問題か? • 解析しやすいようにアノテーションをつける? ‣ etc.
  21. 21. まとめ ‣ コードをプログラマと処理系だけが読めればいい時代は すでに終わり ‣ CASEツールの解析で必要なのは「プログラマがどうい うコードを書いたか」 ‣ マクロがあることを口実にまともにコード解析できない 現状から逃げ続けていいのか?

×