Loading article…
拡張可能プログラミングとは、コンピュータサイエンスにおいて、プログラミング言語、コンパイラ、ランタイムシステム（環境）を拡張するメカニズムに重点を置いたコンピュータプログラミングのスタイルを表すために使用される用語です。このプログラミングスタイルをサポートする拡張可能プログラミング言語は、1960年代には活発な研究分野でしたが、1970年代にはその動きは衰退しました。[1]拡張可能プログラミングは、21世紀に新たな関心を集めているトピックとなっています。[2]
歴史的運動
拡張可能なプログラミング言語運動と通常関連付けられる最初の論文[1] [3]は、M. Douglas McIlroyによる 1960 年の高水準プログラミング言語のマクロに関する論文です。[4]拡張性の原則に関する別の初期の記述は、Brooker と Morris による 1960 年のコンパイラ コンパイラに関する論文にあります。[5]この運動のピークは、1969 年と 1971 年の 2 つの学術シンポジウムでした。[6] [7] 1975 年までに、Thomas A. Standish [1]によるこの運動に関する調査記事は、実質的に事後分析となりました。Forthは例外でしたが、基本的に注目されませんでした。
歴史的運動の特徴
一般的に考えられているように、拡張可能な言語は、基本的なコンピューティング機能を提供する基本言語と、基本言語を変更できるメタ言語で構成されます。プログラムは、メタ言語の変更と、変更された基本言語のコードで構成されます。
この運動で使用された最も顕著な言語拡張技術はマクロ定義であった。文法修正もこの運動と密接に関連しており、最終的には適応型文法 形式論が発展した。Lisp言語コミュニティは拡張可能な言語コミュニティとは別のままであったが、それはある研究者が次のように述べたためと思われる。
プログラムとデータが本質的に交換可能なプログラミング言語は、拡張可能な言語とみなすことができます。...これは、Lispが長年にわたって拡張可能な言語として使用されてきたという事実から非常に簡単にわかります。[8]
1969 年の会議では、Simula は拡張可能な言語として発表されました。
スタンディッシュは言語拡張の 3 つのクラスを説明し、これを言い換え、正語句、メタフレーズと名付けました(言い換えとメタフレーズは翻訳用語です)。
- パラフレーズは、以前に定義されたもの（または定義される予定のもの）と交換する方法を示すことによって機能を定義します。例として、マクロ定義、通常のプロシージャ定義、文法拡張、データ定義、演算子定義、および制御構造拡張が挙げられます。
- Orthophrase は、以前は I/O プリミティブがなかった基本言語に入出力(I/O) システムを追加するなど、基本言語では実現できなかった機能を言語に追加します。拡張機能は、基本言語で定義されていない機能は他の言語で定義する必要があるため、特定の基本言語に対するOrthophrase として理解する必要があります。これは、プラグインの最新の概念に対応します。
- メタフレーズは、既存の表現に使用される解釈ルールを変更します。これは、リフレクション プログラミング(リフレクション) という現代的な概念に対応します。
歴史運動の終焉
スタンディッシュは、拡張性運動の失敗の原因を、連続した拡張をプログラミングすることの難しさにあるとしました。プログラマーは、基本言語の周りにマクロの最初のシェルを構築するかもしれません。次に、マクロの 2 番目のシェルがその周りで構築される場合、後続のプログラマーは、基本言語と最初のシェルの両方に精通している必要があります。3 番目のシェルには、基本と、最初のシェルと 2 番目のシェルの両方に精通している必要があります。以下同様です。プログラマーを低レベルの詳細から保護することが、拡張性運動に取って代わった抽象化運動の目的です。
Simula は拡張可能だと以前から言われていたが、1975 年までに Standish の調査には新しい抽象化ベースの技術は実際には含まれていなかったようだ (ただし、彼は拡張性の非常に一般的な定義を使用しており、技術的にはそれらも含めることができた)。1978 年に発表された、コンピュータの発明からそれまでのプログラミング抽象化の歴史では、マクロについては一切触れられておらず、拡張可能な言語運動が起こったことのヒントもなかった。[9]マクロは、1980 年代後半までに (おそらく衛生マクロの出現により)構文抽象化という仮名を与えられ、抽象化運動に暫定的に受け入れられた。[10]
現代の動き
現代的な意味では、拡張可能なプログラミングをサポートするシステムは、以下に説明するすべての機能を提供します[引用が必要]。
拡張可能な構文
これは単に、コンパイルされるソース言語が閉じていたり、固定されていたり、静的であったりしてはならないことを意味します。ソース言語に新しいキーワード、概念、構造を追加できなければなりません。ユーザー定義構文を持つ構成要素の追加を許可する言語には、Coq、[11] Racket、Camlp4、OpenC++、Seed7、[12] Red、Rebol、Felixなどがあります。一部の基本的かつ本質的な言語機能が不変であることは許容されますが、システムはそれらの言語機能だけに依存してはなりません。新しい機能を追加できなければなりません。
拡張可能なコンパイラ
拡張可能なプログラミングでは、コンパイラはソース コード入力をバイナリ実行可能出力に変換するモノリシック プログラムではありません。コンパイラ自体は、ソース言語入力を任意のものに変換するのに役立つプラグインのコレクションであるほど拡張可能である必要があります。たとえば、拡張可能なコンパイラは、オブジェクト コード、コード ドキュメント、再フォーマットされたソース コード、またはその他の必要な出力の生成をサポートします。コンパイラのアーキテクチャは、ユーザーがコンパイル プロセスに「入り込み」、コンパイル プロセスの適切なすべてのステップで代替処理タスクを提供できるようにする必要があります。
ソース コードをコンピューターで実行できる形式に変換するというタスクだけの場合、拡張可能なコンパイラは次の機能を備えている必要があります。
- 機能のほぼすべての側面にプラグインまたはコンポーネントアーキテクチャを使用する
- コンパイルされている言語または言語バリアントを判別し、その言語を認識して検証するための適切なプラグインを見つける
- 形式言語仕様を使用して、任意のソース言語を構文的および構造的に検証する
- 適切な検証プラグインを呼び出すことで、任意のソース言語の意味検証を支援します。
- ユーザーがさまざまな種類のコード ジェネレーターから選択できるようにすることで、生成される実行可能ファイルをさまざまなプロセッサ、オペレーティング システム、仮想マシン、またはその他の実行環境向けにターゲット設定できるようになります。
- エラー生成とその拡張のための機能を提供する
- 抽象構文木（AST）に新しい種類のノードを許可する。
- ASTのノードに新しい値を許可する、
- ノード間の新しい種類のエッジを許可する、
- 入力ASTまたはその一部の変換を外部の「パス」によってサポートする
- 入力ASTまたはその一部を外部の「パス」によって別の形式に変換することをサポートする
- 内部パスと外部パスが AST を新しい AST または他の表現に変換および翻訳する際に、内部パスと外部パス間の情報の流れを支援します。
拡張可能なランタイム
実行時に、拡張可能なプログラミング システムでは、言語が許可する操作のセットを拡張できるようにする必要があります。たとえば、システムがバイト コードインタープリタを使用する場合、新しいバイト コード値を定義できるようにする必要があります。拡張可能な構文と同様に、不変の基本操作または固有の操作の (小規模な) セットが存在することは許容されます。ただし、新しい動作または追加の動作をサポートできるように、それらの固有の操作をオーバーロードまたは拡張できる必要があります。
コンテンツとフォームを分離
拡張可能なプログラミング システムは、プログラムを処理対象のデータとして扱う必要があります。これらのプログラムには、いかなる種類の書式設定情報もまったく含まれません。ユーザーに対するプログラムの視覚的な表示と編集は、拡張可能なコンパイラによってサポートされる、プログラム データを表示または編集に適した形式に変換する変換機能である必要があります。当然、これは双方向の変換である必要があります。これは、拡張可能なプログラムをさまざまな方法で簡単に処理できなければならないため重要です。ソース言語入力の唯一の用途が、編集、表示、およびマシン コードへの変換であることは受け入れられません。ソース入力を、その処理方法 (書式設定、保存、表示、編集など) の仕様から切り離すことによって、プログラムの任意の処理が容易になります。
ソース言語デバッグサポート
拡張可能なプログラミング システムは、プログラムを実行可能にするために行われた拡張や変換に関係なく、元のソース言語の構造を使用してプログラムのデバッグをサポートする必要があります。最も重要なことは、ランタイム データを表示する唯一の方法が構造体または配列であると想定できないことです。デバッガー、またはより正確には「プログラム インスペクター」は、ランタイム データをソース言語に適した形式で表示できるようにする必要があります。たとえば、言語がビジネス プロセスまたはワークフローのデータ構造をサポートしている場合、デバッガーは、そのデータ構造をフィッシュボーン チャートまたはプラグインによって提供される他の形式で表示できる必要があります。
例
参照
参考文献
- ^ abc Standish, Thomas A.、「プログラミング言語設計における拡張性」、SIGPLAN Notices 10 no. 7 (1975 年 7 月)、pp. 18–21。
- ^ Gregory V. Wilson、「21 世紀の拡張可能なプログラミング」、ACM Queue 2 no. 9 (2004 年 12 月/1 月 - 2005 年)。
- ^ Sammet, Jean E.,プログラミング言語: 歴史と基礎, Prentice-Hall, 1969, セクション III.7.2
- ^ McIlroy, MD、「コンパイラ言語のマクロ命令拡張」、Communications of the ACM 3 no. 4 (1960 年 4 月)、pp. 214–220。
- ^ Brooker, RA および Morris, D.、「句構造言語の一般的な翻訳プログラム」、Journal of the ACM 9 no. 1 (1962 年 1 月)、pp. 1–10。この論文は 1960 年に受理されました。
- ^ Christensen, C. および Shaw, CJ 編、Proceedings of the Extensible Languages Symposium、SIGPLAN Notices 4 no. 8 (1969 年 8 月)。
- ^ Schuman, SA 編、Proceedings of the International Symposium on Extensible Languages、SIGPLAN Notices 6 no. 12 (1971 年 12 月)。
- ^ Harrison, MC、「拡張性の概念に関するパネル」、1969 年シンポジウムの 53 ～ 54 ページ。
- ^ Guarino, LR、「プログラミング言語における抽象化の進化」 [リンク切れ]、CMU-CS-78-120、カーネギーメロン大学コンピュータサイエンス学部、ペンシルバニア州、1978年5月22日。
- ^ Gabriel, Richard P. 編、「共通プロトタイピング システムの要件に関するドラフト レポート」、SIGPLAN Notices 24 no. 3 (1989 年 3 月)、93 ページ以降。
- ^ 「構文拡張と表記スコープ – Coq 8.17.0 ドキュメント」。coq.inria.fr 。2023 年 5 月 25 日閲覧。
- ^ ジンガロ、ダニエル、「現代の拡張可能な言語」、SQRL レポート 47 マクマスター大学 (2007 年 10 月)、16 ページ。
外部リンク
一般的な
- ACM Queue の Greg Wilson の記事
- スラッシュドットディスカッション
- 現代の拡張可能な言語 2011-06-12ウェイバックマシンにアーカイブ– Daniel Zingaroの論文
ツール
- MetaL – 拡張可能なプログラミングコンパイラエンジン実装
- XPS – 拡張可能なプログラミング システム (開発中)
- MPS – JetBrains メタプログラミング システム
拡張可能な構文を持つ言語
- オープンZz
- xtc – 拡張可能な C
- 英語のスクリプト
- ネメルルマクロ
- ブー構文マクロ
- スタンフォード大学中間フォーマットコンパイラ
- Seed7 – 拡張可能なプログラミング言語
- Katahdin – 実行時に変更可能な構文とセマンティクスを持つ言語
- π – Earleyパーサを使用して実装された拡張可能な構文を持つ言語
参照
- {{コンピュータ言語}}
- {{プログラミング言語}}
- {{プログラミングパラダイム navbox }}