matarillo.com

The best days are ahead of us.

9.11 F# 1.0 -- IDEツール

2021-09-25 00:00:21

F# 1.0の重要な要素は、Visual Studio 2005および2008と統合するIDEツールを含めることでした。 このツールの初期の実装は私が行ったのですが、 Project 7に由来する、Daan Leijenによる拡張可能な言語中立ツールのプロトタイプを基にして、 SML.NET用のVisual Studioツールのプロトタイプ実装[Benton et al. 2004]の一部を参照していました。 初期のバージョンは、デモンストレーション目的および愛好家による採用には十分でした。 ただし、このツールの実装中に多くのミスが発生しました。たとえば、

  • オートコンプリートの精度と完全性は当初は良くありませんでしたが、実装にアドホックなケースを多数追加することで修正されました。
  • ツールは、大規模プロジェクトのインクリメンタル編集にもスケールするような設計がされていませんでした。
  • 単一ファイルへのインクリメンタル編集のコンテキストでは、ツールはインクリメンタルではありませんでした。
  • このツールは、C# プロジェクトとF# プロジェクトの両方を含むマルチプロジェクトコードベースではうまく機能しませんでした。
  • ツールの実装は、コード編集機能の最新の進歩(リネームのリファクタリング、コード構造の強調表示、リッチテキストによるコード検査のヒントなど)を念頭に置いて設計されていませんでした。

これらの制限の一部は、実装のベースとしてもともと使用されていたサンプルに起因しており、十分すみやかに修正されませんでした。 全体的にF# コンパイラーコードベースの「コンパイラーサービス」部分の実装は不十分なものになりましたが、一般的なシナリオでの使用には十分効果的だったため、進行中の開発は正当化されました。 これらの問題は、正確性、品質、完全性の観点から、2010年までF# ツールの妨げとなっていましたが、 2015年のF# Compiler Serviceコンポーネントの作成と2017年のその後の改善によってようやく解決されました。

言語設計の観点からは、IDEツールという前提を置くことはC# の設計に強い影響を与えました。 たとえば、C# LINQの構文設計は、「人々がLINQクエリーを入力する際に、優れたIDEサポートを提供できるでしょうか?」という基本的な質問の影響を受けていました。 この仮定は、全体的にはF# 設計自体の推進要因ではありませんでしたが、時折は考慮されました。


インデックスへ戻る