言語は単なる構文ですか、それともフレームワークも含まれていますか？
Pascalの言語履歴を作成する際に、ある時点で、言語が言語とその共通ライブラリの間の強い境界線から、よりぼやけたものに変わったことに気づきました。 Turbo Pascalの最初のいくつかのバージョンでは、バージョン4でユニットが導入されるまで、再利用可能なモジュールの機能はありませんでした。それ以降のバージョンのPascalには、非常に強力な共通ライブラリのコレクションがありました。
Delphiの導入に伴い、[〜＃〜] rtl [〜＃〜]および[〜＃〜] vcl [〜＃〜]が付属しました。特にRTLの場合、言語の一部と見なされることがよくあります。たとえば、例外は言語の一部ですが、適切に処理するにはSysUtils単位を使用する必要があります。さらに、すべてのDelphiプロジェクトで常に使用される組み込みのSystemユニットがあります。
次に、Javaを使用すると、Java言語、JavaランタイムおよびJavaプラットフォーム。Javaプラットフォーム以外ではJava言語を使用できません。
現在、.NETには、フレームワークなしでは存在しない言語であるVB.NETとC＃がありますが、Phyton、Rubyなどは、.NET内となしの両方に存在します。
だから私の質問は、言語は単なる構文とコンパイラですか、それともプラットフォームとフレームワークも言語の一部ですか？線はどこにありますか？なぜまたはなぜそうではないのですか？
答えは完全に文脈に依存します。
厳密に言えば、言語は言語の構文とセマンティクスにすぎず、それ以上のものではありません。コンパイラやインタプリタでさえ数えません。一部の言語には「公式」コンパイラはありません。
標準関数のセットまたは標準オブジェクトライブラリが抽象言語定義の一部である場合、ライブラリはどのコンパイラよりも言語の一部です。たとえば、ECMAScript仕様には、標準オブジェクトの説明が含まれています。
言語は単なる構文（およびセマンティクス）であり、コンパイラー、フレームワーク、またはライブラリーではありません。言語の仕様がわかれば、理論的には誰でもその言語のコンパイラを構築できます。ベンダーはライブラリ/フレームワーク/ランタイムを言語とともに出荷できますが、それが言語の一部であるという意味ではありませんそれ自体。 ...以下のコメントで読むことができますが、いくつかの重要なコア関数またはライブラリが言語仕様で参照できる場合があります。そして、おそらくそうでない他の言語もありますが、私は確かに知るのに十分な言語仕様を読んでいません。
言語はコンパイラと標準ライブラリの2つによって定義されると私はいつも考えてきました。コンパイラーは、明らかに、言語の構文とセマンティクスの具体的な定義と解釈を提供しますが、IMOは通常、それを使用して作成されるプログラムの種類に最も影響を与える標準ライブラリーです。
たとえば、Delphiについて言及しました。 Delphiはチューリング完全であり、理論的には計算可能なプログラムの作成に使用できます。 PHPもチューリング完全であり、理論的には計算可能なプログラムの作成に使用できます。しかし、Delphiで作成されたGUIベースのデスクトッププログラムや、PHPで作成されたインタラクティブなWebサイトがたくさんあります。 、そしてその逆はあまりありません。
何故ですか？これは主にライブラリによるものです。 DelphiにはVCLが標準機能として付属しており、多くの言語設計（特に、Delphi1とTurboPascal 7を区別する変更）は、VCLを正しく機能させるため、またはVCLのフォームデザイナーをIDE正しく機能します。ウィジェットライブラリのゴールドスタンダードを標準機能として持つことは、GUIプログラムを構築したい人々を引き付ける傾向があり、一般的にはRAD言語。
一方、PHPには、テキスト処理、HTMLテンプレート、データベース通信用のライブラリ関数が多数あります。これにより、Webサイトの構築が非常に簡単になるため、Webサイトを構築したい人を引き付ける傾向があり、一般にWebスクリプト言語と考えられています。
多くの単語にはさまざまな意味があるように思えます。
たとえば、体とは、全身、頭のない体、腕/脚/頭のない体を指します。同様に、腕には腕の一部として手を含めることも、腕を手と区別して見ることもできます。
言語も同じカテゴリーに入ると思います。その最も具体的な形式では、言語はその構文とその構文のセマンティクスを指していると思います。最も一般的な形式には、構文、標準ライブラリ、使用されている外部ライブラリ、さらにはプログラマー側のスタイルも含まれます。
現在、私は明らかにCの経験が豊富な人によってC++で書かれたプロジェクトに取り組んでいます。ある意味で、私が思っていたC++とは異なる言語「C++-」であると説明します。通常は書き込みます。
私は欲求不満に同意します。 「言語」とは、その言語の仕様で定義されているものだけです。これは、基本的に、構文、キーワード、演算子、およびそれらの動作を意味します。たとえば、C＃の仕様を考えると、進取の気性のある個人は、.NETFrameworkなしで動作するプログラムを生成するコンパイラを作成できます。
ただし、ほとんどの言語では、ある種の「ランタイム」が必要です。 C/C++のような「管理されていない」言語で作業している場合でも、WindowsとMFC、Linux、さらにはMacをターゲットにすることができます（ただし、Appleは、Obj-CがApple OSes）の開発に使用される唯一の言語。これは、さまざまなOSが提供するライブラリを利用することで発生します。これにより、通常、プログラムはOSのGUIにプラグインし、OSレベルを利用できます。 OpenGL/DirectXなどのハードウェアアクセスツール。
ただし、通常、ライブラリのコレクションだけを「ランタイム」とは考えていません。一般に、JVMやCLRのようなメモリ管理された「仮想マシン」について考えます。これらのプラットフォームは、相互運用、ハードウェアアクセス、および一般的な構造のライブラリに加えて、メモリの「サンドボックス」、およびガベージコレクションやCASなどの「シャペロン」を提供します。これらは、特定のファームウェアの本質からプログラムのロジックをさらに抽象化します。それが実行されるハードウェア。
その質問に答えることには常に曖昧な側面がありました。
どの言語にも標準のランタイムが必要です。たとえば、なんらかのランタイムがないと、any Cプログラムを実行することはできません。プラットフォームはmainを呼び出す方法を知りません-ランタイムライブラリは、プラットフォームの規則に従って呼び出され、コマンドラインパラメータを解析し、mainを呼び出すエントリポイント関数を提供する必要があります。その後、プラットフォームが提供することを期待します。終了値。
すべてのプラットフォームがプログラムのエントリポイントを呼び出す方法についての普遍的な規則がないため、ランタイム必須複数のプラットフォームで実行できる任意の言語でそのギャップを埋めます。
ランタイムは、コンパイラーと同様に、言語標準（公式標準が存在する場合）に従っても定義されていません。たとえば、関数（標準ライブラリなど）の呼び出し規約の詳細を定義している言語はほとんどありません。これらの詳細はプラットフォームに大きく依存しているためです。したがって、ライブラリのタイプと関数のセット、およびそれらの動作は標準で定義できますが、実装の詳細の多くはそうではありません。
コンパイラとライブラリの間にも驚くべき相互作用がある可能性があります。ライブラリをインポートするときに、コンパイラがヘッダー/ライブラリやプリコンパイル済みモジュールなどをまったく参照しない場合があります。通常、効率上の理由から、コンパイラは呼び出しを組み込みの実装に置き換えます。
ただし、通常は、エントリポイント関数に至るまで、標準ライブラリのほとんどまたはすべてを置き換えることが可能です（場合によっては非常に実用的です）。一部のパーツでは、アセンブラコーディングが必要です。一部のビットでは、いくつかのオプションを設定する必要があり、それらの組み込み実装を使用できません。しかし、交換is多くの場合可能です。
一部の言語は、本質的にコンパイラと提供されたライブラリの間に非常に密接なリンクがあるため、代替ライブラリを使用する唯一の正しい方法は、代替コンパイラも使用することです。これはおそらく最近ますます多くのケースであり、.NETやJavaプラットフォームなどのフレームワークと、C＃やもちろんJavaなどのサポートする言語との密接な関係があります。
- おっと-もちろん、プラットフォーム自体が標準化されているため、同じコンパイラを使用しながら、.NETまたはJavaプラットフォーム全体を代替実装に置き換えるのは非常に簡単です-仮想マシンコードに至るまで。 ごめんなさい。
おそらくまだ完全な置換ランタイムが比較的見られる可能性が高いコンテキストの1つは、組み込みシステムですが、携帯電話を意味するわけではありません。おそらく、洗濯機。
C++のBjarneStroustrupsの原則の1つは、プログラマーができないことは言語でできないことであるということでした。たとえば、ライブラリ開発者が型を持つ演算子をサポートできるように、演算子のオーバーロードがあります。Cでは、コンパイラの組み込み型のみが演算子をサポートできます。ただし、これにはアセンブラプログラミングが必要な場合があります。もちろん、低レベルのO/Sアクセスを提供する方法がすでにない限り、C++で直接低レベルのO/SアクセスとI/O機能を提供するライブラリを作成することは不可能です。およびI/O機能。
つまり、基本的にはそれだけです-ランタイムの使用を完全にオプトアウトすることはできませんが、ランタイムの大部分の使用をオプトアウトすることはできます。may実行できないパーツを置き換えることができます。なしで、またはすべてを置き換えることさえできます。
「言語」は、その言語の標準仕様によって最も正確に定義されています。これはCODASYLISO ECMAなどの標準である可能性がありますが、ほとんどの言語には公式または非公式の標準定義があります。
したがって、COBOLの場合、「言語」は構文を指し、構文に関連付けられた動作-たとえば、算術演算中に数値が切り捨てられて丸められる方法について非常に具体的です。
FORTRANの場合、標準で定義されている「言語」には、常に構文、動作、および標準ライブラリの実装が含まれています。 SIN（）やPRINTF（）などを実装しないと、コンパイラーをFORTRANとして認定することはできません。
Java重複する標準のコレクションがあります。構文とその結果の動作が基本標準を形成しますが、実質的にはMicro、Standard、EnterpriseEditionの3つの言語があります。これらは共有します。同じSYNTAXルールですが、仮想マシンと関連ライブラリの標準が異なります。カジュアルな会話以外では、専門家が「何で書かれているのか」という質問に「Java SE」。
したがって、精度と実用的な目的の両方で、「言語」は、SYNTAXの予想される動作と、それに関連する実行時間およびライブラリを指します。
意図的により一般的にしたい場合は、「ほとんど/任意の.....方言で」という表現を使用して、次のように、より一般的なことについて話していることを示すことができます。
「BASICのほとんどの方言で 'LET A = 1'が機能します」または「どのCOBOLでも、英数字変数に対して算術演算を実行することはできません」。