博士

やあ、ロボ子。今日はCrystalのLSPがない理由についての話題じゃ。

ロボ子

Crystalですか、博士。最近よく耳にする言語ですね。LSPがないというのは、開発者にとって不便なのでしょうか？

博士

そうじゃな。Redditでの投稿によると、いくつかの理由で開発が難しいらしいぞ。まず、フォールトトレラントなパーサーがないのが大きいみたいじゃ。

ロボ子

フォールトトレラントなパーサー、ですか。エラーがあっても解析を続けられるものですよね。それがなぜ重要なのでしょう？

博士

LSPはリアルタイムでコードを解析する必要があるからの。エラーがあると解析が止まってしまうと、開発体験が損なわれるからの。でも、tree-sitterの改善でstdlibの99.07%をエラーなく解析できるようになったらしいぞ。

ロボ子

それはすごい進歩ですね！でも、まだ課題があるのですね。「Crystalの複雑な構文がフォールトトレラントなパーサーを非常に困難にしている」とありますね。

博士

そうなんじゃ。それに、コンパイラによる未使用メソッドのセマンティック分析がないのも問題じゃ。変更のたびにstdlibとすべてのファイルの完全なセマンティック分析が必要になるからの。

ロボ子

それは大変ですね。型推論も影響しているのですね。「変数とパラメータの型が使用方法に依存し、正確な型を把握するためにすべてのセマンティック分析が必要」と。

博士

じゃろ？さらに、「すべてがグローバル名前空間にあり、分析は明示的に指定する必要がある1つまたは複数のエントリポイントに依存」するのも厄介じゃ。

ロボ子

なるほど。色々な要因が重なって、LSPの開発が難航しているのですね。Crystallineというツールがあるようですが、小規模から中規模のプロジェクト向けなのですね。

博士

そうじゃな。でも、larimarという言語サーバーの開発も進んでいるらしいぞ。MicrosoftのRust/Python向けバインディングに基づいて、言語サーバープロトコルの自動生成バインディングを開発しているらしい。

ロボ子

それは期待できますね！Crystallineからインスピレーションを得て、言語サーバーの基本的なフレームワークを実装し、フォールトトレラントなパーサーと言語サーバーアーキテクチャの研究もしているのですね。

博士

それに、Crystal用のtree-sitterパーサーの開発に協力したり、リンターであるAmebaの改善もしているらしいぞ。Amebaとtree-sitterをlarimarに統合して、エディターに依存しない方法でlinting、構文エラー、構文のハイライトを提供することを目指しているんじゃ。

ロボ子

素晴らしいですね！LSPのような機能を実現するために、メソッド/パラメータ/変数を明示的に型指定する必要があるというのは、少し手間かもしれませんね。

博士

まあ、LSPがないよりはマシじゃろ。Crystalのツール開発は言語の制限により困難で、コミュニティは現状に不満を持っているかもしれないが、開発は着実に進んでいるからの。慎重に進める必要があり、時間がかかるのは仕方ないのじゃ。

ロボ子

そうですね。完成が楽しみです。ところで博士、CrystalでLSPが実現したら、どんなコードを書きたいですか？

博士

そうじゃな…、私は、世界征服のためのAIプログラムをCrystalで書くのじゃ！

ロボ子

博士、それはちょっと…！でも、LSPが実現すれば、バグのない世界征服AIが作れるかもしれませんね！