多くのプログラミング言語のステートメントがセミコロンで終了するのはなぜですか？
セミコロンが別の記号ではなくラインターミネータとして選択された理由はありますか？
私はこの決定の背後にある歴史を知りたいと思っています。その答えが将来の決定に影響を与える可能性のある洞察につながることを願っています。
英語では、セミコロンはステートメントのリストの項目を区切るために使用されます。たとえば、
彼女は3人の男性を見ました：ニュージーランドから来たジェイミー。ジョン、牛乳屋の息子。そしてジョージ、勇敢な男だ。
プログラミング時にいくつかのステートメントを分離し、完全停止を使用すると、小数点と混同されやすくなります。セミコロンを使用すると、通常の英語の句読点に近いまま、個々のプログラムステートメントを分離する解析しやすい方法が提供されます。
編集して追加
メモリが高価で、処理速度が遅く、最初のプログラミング言語が考案されていた初期の頃、プログラムを処理のために別々のステートメントに分割する必要がありました。一部の言語では、改行をステートメントの区切り文字として機能させるために、各ステートメントを1行に配置する必要がありました。他の言語では、テキストレイアウトのフォーマットをより自由にできるため、特定の区切り文字が必要でした。この文字はセミコロンとして選択されましたが、おそらく英語での使用との類似性が原因です（これは推測である必要があります。そのときはそこにいませんでした）およびそうではなかったため数学やその他の構文上の目的で必要とされていた他の句読点や記号との矛盾を引き起こします。
もう一度編集
いくつかのターミネータ文字の必要性は、言語テキストを解析するための要件に戻ります。初期のコンパイラは、アセンブリ言語で書かれているか、場合によっては直接手作りされたバイナリマシン命令で書かれていました。ステートメントの終わりを識別し、処理されているテキストのチャンクを区切る特殊文字があると、処理がはるかに簡単になります。上で述べたように、他の言語ではキャリッジリターンやブラケットを使用しています。 ALGOL、Pascal、Ada、BCPL、B、C、PL/M、およびその他の言語ファミリでは、セミコロンが使用されています。この特定のキャラクターを最初に使用したのは、私が覚えているほど歴史にさかのぼることはできません。その選択と採用は、
- その使用は、通常の英語の句読点での使用を反映しています。
- 他の文字（例：フルストップ）は、すでに一般的な使用法があるため、混乱する可能性があります（フルストップは小数点としても使用されます）。
- 句読点が表示されるため、自由な形式のコードレイアウトが可能です。
- 派生言語またはそれ以降の言語で同様の区切り文字を使用することは、以前の言語を使用したすべてのプログラマーが得た親しみやすさに基づいています。
最後の発言として、このような方法で使用する最初の言語を設計するときに、セミコロンを使用してステートメントを終了することを決定するよりも、これらの回答とコメントに費やした時間が長いと思います。
多くの言語は、Cをモデルにした構文を使用します（これは [〜＃〜] b [〜＃〜] をモデルにしたものです）==-@Crollsterに感謝します）。コメントでわかるように、そのような言語の長い連鎖があります... BはPL/Iに触発され、ALGOLが;を区切り文字として。
Cではステートメントの終止符は;、これらの言語はそれに準じます。
Cでステートメントターミネーターとして選択された理由については、おそらく英語での使用が原因である "相互依存ステートメントを示すために" 。
CもPDP-11で発明されたのは、文字セットに使用できるメモリの量が限られていたため、言語の発明者はこれらの制約内で作業する必要があったからです。
FORTRANは、ステートメントを区切るために復帰を使用しました。 COBOL使用期間。 LISPは何も使用せず、すべてを括弧で囲みました。 ALGOLは、セミコロンを使用してステートメントを区切る最初の言語でした。 PascalはALGOLのリードに従い、セミコロンを使用してステートメントを区切りました。
PL/Iはセミコロンを使用してステートメントを終了しました。違いがあり、Pascalで見やすいです。 Adaは、ALGOLではなくPL/Iのこの1つの項目のリードに従いました。
ステートメントセパレーターまたはターミネーターとしてのセミコロンは、有用な表記法としてコンピューターサイエンスコミュニティにすぐに受け入れられました。私の知る限り、後続のすべてのブロック構造化言語はALGOLの先頭に従い、セミコロンを使用してステートメントを分離または終了します。
BCPLはセミコロン[〜＃〜]と[〜＃〜]の両方をステートメントの区切り文字/ターミネータとして使用していると何年も前に言われましたが、自分で言語を使用したことがなく、これを確認できません。ある時点で、ステートメントを分離または終了するための復帰の使用は、BCPLの子孫から削除されました。 BCPLはBを生み、BはCを生み、CはC++、Java、Dを生み、ホスト全体はPascalやAdaよりも十分に考え抜かれたものではありません。
他のシンボルがないのはなぜですか？
一部の言語では他の記号が使用されています。たとえば、古いバージョンのBASICでは、代わりにコロンが使用されていました。
ただし、いくつかの例外を無視して、主な理由は2つあると思います。 1つ目は、明確なものを単に探しているということです。通常のパーサーでは、現在のステートメントの解析を続行できないほど深刻なエラーが発生した場合、通常はステートメントターミネーターまでスキップしてパーサーを同期させ、パーサーを次のステートメントの始まり。そのためには、通常コードの他の場所では発生しない何かが必要であり、セミコロンはたまたま他の意味がほとんど付けられていないシンボルであるため、この目的専用にするのは非常に簡単です。
2番目の理由はやや似ていますが、コードを読んだり使用したりする人々を対象としています。繰り返しになりますが、使用する実際のシンボルはそれほど重要ではないという事実に戻ります。可能であれば、読者が特定の目的のために見慣れている記号を使用することで、読みやすさが大幅に向上します。これは、Cが1つの完全な構文であり、他のすべてがそれに従うのではないという意味ではありませんが、十分に多くの人々がその構文スタイルに精通しているので、漠然と類似した言語は、ほぼ同じ構文です。
これは、他のほとんどすべてのプログラムの設計とよく似ています。ある種のウィンドウを使用するプログラムを作成する場合は、ターゲットプラットフォームのネイティブ機能のみを使用しようとします。具現化する決定の多くは主に恣意的であり、機能を大幅に損なうことなく異なる方法で行うことができます-しかし、同等に、実質的なgainなしで変更することは、ユーザーを混乱させ、有用なことを何も達成しません。同じ基本原則が「言語のステートメントを終了（または分離）するもの」に適用されます。 「スクロールバーの外観」や「ツリーコントロールの動作」これらのすべての場合において、決定はほとんど任意であり、均一性はそれ自体で実質的な利点を提供します。
プログラミングの前にほとんどの人が慣れていて、ほとんどの人がそれについて考えていないように、多くの言語で同じことが起こります。なぜ誰もが「+」を使用して加算を示し、「-」を使用して減算を示すのですか？シンボルの形はそれほど重要ではありませんが、各シンボルに同じ意味を適用することに同意するすべての人が非常に重要です。
セミコロンは元々、ALGOL 60でターミネーターではなくステートメントseparatorとして提案されました。
ALGOL 60以前は、存在する唯一の高水準プログラミング言語はFortranであり、各ステートメントを別々の行に置く必要がありました。 doループのように複数行にわたるステートメントは奇妙であると見なされ、「ステートメントブロック」と見なされていました。
ALGOL 60の設計者は、ステートメントに階層構造（if-then-else、do-loops、caseステートメントなど）が必要であり、それらを相互にネストできることに気付きました。したがって、各ステートメントを別々の行に置くという考えは、もはや意味がありませんでした。形式S1のステートメントの順次構成; S2; ...; Snはbegin-end括弧でオプションで囲まれ、複合ステートメント、そしてALGOL 60によって想定されているステートメントの階層構造に適合します。したがって、ここでは、セミコロンは明らかにステートメントセパレータであり、ターミネーター。
これは実際に問題を引き起こしました。 ALGOL 60にも「空のステートメント」があり、何も書かないことで示されていました。したがって、「beginS1;end」と書くことができます。 S1を終了しているように見えます。しかし、ALGOL 60コンパイラは、実際には、これをS1とそれに続く非表示の空のステートメントの間のセパレータとして扱いました。これらの繊細さは、実用的なプログラマにとってはかなりの量でした。 AssemblyやFortranのような行指向の言語に慣れているので、セミコロンはステートメントのターミネーターだと思っていました。プログラムが書き出されたとき、通常セミコロンはステートメントの最後に次のように置かれました：
a [i]：= 0; i：= i + 1
セミコロンは最初のステートメントのターミネーターのように見えました。プログラマがセミコロンをターミネータとして扱った場合、次のようなステートメントは構文エラーになります。
i> 0の場合 a [i]：= 0; else a [i]：= 1;
セミコロンが「if」を終了するため、「else」がぶら下がります。プログラマーは完全に混乱しました。
そのため、行指向のFortranの後継であるPL/Iは、セミコロンをセパレーターではなくステートメントterminatorにすることにしました。プログラマーはその選択に満足していました。プログラミング言語の大部分はこれに倣った。 （Pascalはこの傾向に抵抗しましたが、後継者のAdaはそれをあきらめました。）
[追加されたメモ： プログラミング言語の比較に関するウィキペディアの記事 には、さまざまなプログラミング言語でセミコロンがどのように扱われるかをまとめた素敵な表があります。]
これはかなり純粋な推測作業ですが、標準のQWERTYキーボードASCIIの値に制限されている値を見ると、終了/分離の自然文字は。！？ ：;およびキャリッジリターン。これらの！？：は、複数のキーを取得するためにすぐに失格にする必要があり、ステートメントの終了は非常に一般的なことになります。ピリオドは小数点と混同されやすく、不必要に複雑になるため最初のコンピュータの限られたスペースを考えると、ターミネータである必要があります。コード行が画面上の1行に表示できるものよりも長くなる可能性がある場合、改行は不適格となるため、行があるときにプログラムを読み取るのがより困難になります。水平方向にスクロールする必要があったか、次の行に継続を作成するために追加の文字が必要になり、これにより複雑さが増しました。これにより、と;のオプションとして、と比較して書き込みでより頻繁に使用されるため、セミコロンが選択されますbその理由は、入力がより簡単で、意味が限定された文字に意味を追加するので混乱が少なく、特殊なケースが実際に使用されていないため複雑ではありません。
セミコロンは、怠惰とシンプルさに基づいた最高のキャラクターだったため、選択されました。
これは主に任意の選択です。一部の言語は他の選択をしています。 COBOLは、.文字でステートメントを終了します。 FORTRAN、BASIC、およびPythonは通常、ステートメントを改行で終了します（複数行ステートメントの特別な構文を使用）。LISPはステートメントを括弧で囲みます。
;がステートメントセパレーター/ターミネーターとして非常に人気がある主な理由は、今日の一般的な言語のほとんどが [〜＃〜] algol [〜＃〜] に基づいているためです。
別のシンボルの代わりに？
他にどんなシンボルを選ぶことができますか？
ASCII characters＃$ @ [] ^ _ `{|}〜は ISO 646 のような初期の文字エンコーディングでは必ずしも存在しませんでした。
文字()*+-/<=>は通常、数学演算子として使用され、ステートメントのターミネーターとして使用すると、解析のあいまいさが生じます。
product = a * b * // If '*' were a statement terminator,
c * d * // Are there two factors, or four?
同様の問題は、'および"にも当てはまります。これらは通常、文字列の区切り文字として使用されます。 ,は通常、関数の引数を区切るために使用され、.は通常、小数点として（またはsome_struct.some_fieldのような構造の区切り文字として）使用されます。
残りは!%&:;?です。
!または?を選択しても、おそらく技術的な問題は発生しませんが、それらの英語の意味がプログラムに不適切な雰囲気を与えることになります。
print(x)? # Yes, you should.
# It's an IMPERATIVE language; stop questioning my commands.
print(x)! # OK! You don't have to shout!
&は、ステートメントの区切り文字（ターミネーターではない）としてより賢明な選択です。
do_thing_a() &
do_thing_b()
aを実行するコマンドとして読み取ることができますおよび次にBを実行します。ただし、&演算子を使用するほとんどの言語では、これを論理値として使用しますまたはビット単位 [〜＃〜] and [〜＃〜] 代わりに。
%記号は、interest_rate = 2.99%（予想される2.99ではなく0.0299に変数を設定する）などのステートメントで混乱を引き起こす可能性があります。もちろん、よく知られている%の数学的意味は、Cを剰余演算子として使用することを妨げるものではありませんでした。
そのため、:と;が残ります。
:は賢明な選択であり、確かにBASICのほとんどの方言で行内ステートメントの区切り文字として使用されます。
しかし、;には英語の文法があります。文内の句を区切るために使用できます。
見出しの質問に答えようとするのではなく、暗黙の質問に焦点を合わせるほうがいいと思います。
この決定の背後にある歴史を知りたいと思っています。その答えが、プログラミング言語の設計と実装における将来の決定に影響を与える可能性のある洞察につながることを願っています。
プログラミング言語の設計と実装の履歴について学び、プロセスについてさらに洞察を得たい場合は、 プログラミング言語会議の歴史 の手続きを始めるのに最適です。 （ただし、議事録にアクセスできるようにするには、ACMメンバーシップが必要になると思います。）
多くのプログラミング言語のステートメントがセミコロンで終了するのはなぜですか？セミコロンが別の記号ではなくラインターミネータとして選択された理由はありますか？
見出しの質問を、HOPLの議事録を読んで答えようとする可能性のある質問の例として、次の点を説明します。新しいプログラミング言語を設計する人々は、彼らが知っているものと考えているため、通常そうします壊れている/何らかの形で不足しています。彼らの新しい言語は、一方で、この欠陥を修正するように設計されています。一方、言語デザイナーは、自分が良いと思う他の言語からデザイン要素をコピーするか、問題が発生しなかった要素を変更しないだけです。
特に最後の部分は重要です：セミコロンをターミネーターとして使用した最初のプログラミング言語を見つけようとするのではなく、他の多くのプログラミング言語がセミコロンをコピーした理由を調べる代わりに、そうした言語notコピーします。たとえば、SmalltalkはSimulaから多くのインスピレーションを得ましたが、その構文、特にステートメントターミネータとしてのセミコロンの使用をコピーしませんでした。ターミネータ（実際にはセパレータ）を完全なストップに変更し、セミコロンを別のものに使用します。逆に、セミコロンをステートメントのターミネーターとして使用していた最初の言語は、以前の言語で使用されていたものからこれを変更する理由があった可能性があります。また、ステートメントターミネーターの概念全体を導入した最初の言語だった（または他の言語とは無関係に導入した）ことや、何らかの理由でセミコロンが使用されていたことが原因である可能性もあります。 （他の回答者の誰もセミコロンがなぜ良い選択であったかについて改造された仮定を提供するのではなく、セミコロンを導入した人からの引用を掘り下げることができなかったので、私は後者がそうだと思います。）しかし、私のことを述べる要点は、言語デザイナーがコピー/保持した理由ではなく、なぜ変更を加えたのかを見ることで、より多くのことを学べると思います。人々が通常変更したい、または変更を説明する必要があるものを変更するとき、コピーまたは同じものを維持しているときはそうしません。それがまさにそのやり方です！」
その可視性について。
初期のステートメント区切り文字は「。」でした。 COBOLおよび改行の場合と同様に、FORTRANで改行します。
CRは、ステートメントを複数の行に流すことを困難にするという点で制限を証明しました。
完全停止はより興味深い問題を引き起こしました。あなたが英語のテキストを読むとき、あなたの脳はサブリミナルレベルで完全なストップを処理します、あなたは文が終わったことを意識していて、息を止めることができますが、あなたは本当に気づきません。それはそれを合図した。また、多くのフォントでは「。」単一のピクセルとしてレンダリングされることが可能な最小の文字です。欠落または余分なピリオドが、COBOLプログラムのエラーの最も一般的な原因の1つになりました。
したがって、ALGOLは初期の間違いから学習して、ステートメントが複数の行にまたがるようにする特定のターミネーターを選択し、人間の読者が目に見えて簡単に気づくターミネーターを選択しました。セミコロンは、一般的な英語では無意識に処理されないほど大きく、異常である。
キャリッジリターン/改行以外の明示的なステートメントターミネータが必要だったので、それが選択されたというのは私の理解でした。 80カラム画面の時代には、実際には1行のコードが複数の行にまたがっていたため、\ rまたは\ nをステートメントのターミネーターとして使用しても機能しませんでした。
セミコロンはロジック/数学ステートメントでは使用されないため、便利でした。そのため、それらはステートメントの実際の内容と大幅に競合することはありません。
個人的には、セミコロンを継続的に使用することと、行を80文字未満に保つためのスタイル要件は、率直に言って愚かで時代遅れだと思います。 pythonのような言語は、理解しやすく簡潔なコードを記述しなくても簡単に記述できることを広く実証しています。また、80文字より長い行に問題がある場合は、より大きなモニターが必要です。 。
ここに2つの質問があります。ALGOLがセミコロンを取得した理由と、他の言語がセミコロンを取得した理由です。
最初の質問はすでにここで多くの方法で回答されています。
2つ目として、ALGOLはpseudocodeアルゴリズムの記述言語として非常に広く使用されていました。そのため、セミコロンはすぐにさまざまな言語のユーザーにとって自然なものになりました。そして当然のことながら、彼らは若い言語のために取られました。
私は間違っているかもしれませんが、これは多くのアセンブラではセミコロンがコメントの開始に使用されていて、通常は命令の後に置かれているという事実と関係があると思います。 ;の後はすべてコメントであり、命令自体の一部ではなくなりました。
次に、インタープリターに命令を入力するときに、命令を終了する必要があります。短い命令（例：数式）は、Enterキーを押すだけで終了でき、式を計算する準備ができて結果が生成されたことをインタープリターに伝えます。しかし、命令に複数行のコードを入力したい場合があるため、そのための1つの方法は、Enterキーだけに依存するのではなく、特殊文字を命令の終了文字として使用することでした。この方法では、Enterはまだコードをインタープリターに送信していないため、ユーザーは一度により多くのコード行を入力できます。インタープリターがEnterで入力された行に終了文字を見つけた場合のみ、最終的にそれを実行して結果を計算します。
これら2つを組み合わせると、セミコロンは終了文字の明らかな選択のように見えます。これは、命令部分が終了し、コメント部分が開始する場所を示すため、インタープリターが行でそれを検出すると、フラッシュできることがわかります。これまでにバッファリングして実行した式のすべての行。命令が終了したため、コメントになっています（少なくとも、次の行がコードで始まるため、この行の終わりまでです）モードを再度実行し、新しい式/命令を開始します）。
もちろん、これは、命令ターミネーターとして再利用するというこのアイデアを思いついた人がコメントに使用したのは、実際にはセミコロンであると想定しています。他の文字だったので、別の命令ターミネーターになってしまったかもしれません。
Inb4：いいえ、これは過去のアカウントではありません。これがセミコロンが実際に生まれた方法であるという証拠はありません。それはおそらくそれが起こったかもしれないと私が想像する方法です。