新しいツールも知られています。これらのツールは、構成ファイルまたは一連の実行可能なコマンドを記述するために独自の形式を使用しており、「プログラミング言語」の概念に非常に近いものです。
この記事の目的は、コンピューターと人との間のコミュニケーションのための普遍的なツールになることができる抽象的なプログラミング言語の期待と可能な実装を定式化することです。
プログラマーについて。
最初から始めると、「すべてのプログラマーは自分のデータベース、テキストエディター、プログラミング言語を作成する必要があります」という言い換えを聞いたことがあります。そして、私がずっと前に最初の2つのことを書いたとしたら、プログラミング言語はまだうまくいきませんでした。
結局のところ、プログラミング言語は通常どのように作成されていますか？
すべてのプログラマーは、常にある種の以前の経験を持っています。
- 1つまたは複数のプログラミング言語の知識（それがなければどうなるでしょうか）
- それらを使用することによる否定的な経験（そうでなければ、すべてがあなたに合っているなら、なぜ何か新しいものを思い付くのですか？）
- 新しい機会を得たい（既存の言語に何かが欠けている場合）。
そして、構文を説明し、キーワードを選択し、主要な作業（レクサー、パーサー、ベースライブラリ）を開始する前に、基本的な質問に答える必要があります。
- コンパイラー/インタープリター/トランスパイラー？
- 静的または動的タイピング？
- 手動メモリ管理またはガベージコレクターによる自動？
- プログラミングモデル：OOP、機能、構造、または何か新しいもの？
- 他のプログラミング言語などからの挿入は許可されていますか？
私は、おそらく、ほとんどの読者のように、いくつかのプログラミング言語を使用した経験があります。したがって、問題を解決するには、独自の言語を書き始めるのではなく、よく知られている言語を使用するか、新しい言語を学ぶ方がよいというのが長い間慣習でした。
さらに、私はダニのために、または言語自体のために別の言語を発明したくありません。それを作成する目的は、開発者自身のニーズの外にあるべきだと私は信じています。
そして、プログラミング言語の開発が求められる分野をなんとか決定できたように思えます。それに費やされた努力は、真の利益をもたらすことができます。
非プログラマーについて。
この領域は、プログラマー以外の人のための自然な言語プログラミングです。「プログラマー以外」と「ナチュラル」という言葉は、意図的に引用符で囲んでいます。これらの用語は非常に条件付きです。
結局のところ、プログラマーがプログラミングを開始しない場合、それを認識せずに、彼は自動的にプログラマーになります;-)。定義上、プログラミング言語を「自然」にすることはできません。より正確には、コンピューターの場合、アセンブラー言語または一連の機械命令は「自然」である可能性が最も高いでしょう。
したがって、目標は最大です-プログラミング言語を自然な人間の言語に近づけることです。
これにより、プログラムのテキストを非専門家が読みやすくなるだけでなく、最小限の基本的なルールを使用して、書かれたスピーチを習得するだけでプログラムの作成を開始できるようになります。
しかし、この言い回しには非常に大きな問題があります！
すべてのプログラミング言語は国際的です。その構文は、プログラマーが通信する自然な言語とは無関係です。
そして、プログラムのテキストが「自然な」言語である場合、それはこの言語を知っている人だけが理解できるようになると同時に、他の人には理解できなくなります。
実例として：1回または2回。
そのような言語の希望について想像すると、次の要件と制限が表示されます。
- ( ), , , , .
- / , «» , «» .
- 私は本当に新しい言語での寛容、混乱への
寛容を見たいと思っています。そのような「特徴」は自然な言葉で書かれていることに存在し、タイプミスの存在にもかかわらず、その意味はほとんど常に保存されています。当然のことながら、この場合、狂信的なところまで行くべきではありません。コンパイラは心を読み取らず、ユーザーの意味を実際に「理解」することはできませんが、コンテキストに基づいてプログラムテキストのタイプミスを無視することは非常に一般的です（警告メッセージはありますが）。
それにもかかわらず、そのような言語は、機能的およびオブジェクト指向のプログラミングや書かれたものの明確な理解を含む、あらゆるレベルの複雑さのプログラムを作成するすべての可能性を備えた単なるプログラミング言語のままでなければなりません。
架空の言語について
執筆規則に基づくと、新しい言語の基本的な規則と句読点は次のようになります。
- すべてのテキストは文とコメントで構成されています。提案は処理され、コメントは無視されます。
- 文は、一連の用語、文字、記号で構成され、スペースと句読点で区切られ、文末文字で終わります。
- 用語は、文字、数字、記号「：」と「_」の融合したシーケンスです。
- 文字通り-プログラムのテキストに直接含まれる定数で、そのタイプは一意に決定されます。これらは、引用符、整数、実数の文字列、およびいくつかの特別な形式（時刻、日付）です。
- シンボル-句読点、空白、数字、文字に属さないその他すべてのシンボル。
- — , :
- «.»,«;»,«!»,«?»,«…» — .
- «=» — .
- "" () — .
- «()» — / .
- «[]» — .
- «{}» — .
- «$» — .
- «@» — .
- «,» () — .
- «:» () — .
割り当て記号、引用符、括弧、および角括弧を使用してすべてを多かれ少なかれ明確にする必要がある場合は、それらの目的は、圧倒的多数のプログラミング言語の目的に対応しているので、残りの文字（中括弧、コロン、コンマ、およびシステム関数/変数）の目的を少し説明する必要があります。
架空のプログラミング言語の目標はまだプログラムを書くことであるため、自然言語に固有のすべての可能性と曖昧さを考慮せずに、通常のプログラムコードを挿入する可能性を提供する必要があります。
この機能は、低レベルの関数を実装し、外部ライブラリと対話するためにも必要です。
このような挿入を作成するときは、中括弧を使用できます。その間のすべてのテキストは、ほとんどまたはまったく処理せずに最終ファイルに挿入されます。
記号「$」（システム変数）と「@」（システム関数）も同様の目的を果たします。そのような記号が単語の先頭に配置されている場合、それは対応する目的を持つオブジェクトを示します。たとえば、「@ exit」は関数を意味し、「$ var」は適切な名前の変数を意味し、オブジェクト自体は通常のコードと中括弧内のプログラム挿入の両方で使用できるようになります。
オブジェクトの個々のフィールド/メソッドへのアクセスは、
「object @method」または「object $ field」と同様の方法で編成されます。
カンマ文字「、」は、1つの文で等しい論理ブロックのシーケンスを示すため、またはリストを作成するために使用されます。
コロン文字「：」は、リストを作成し、完全なモジュールパスを含む、単語/テキストの2つの部分間の論理関係を示すために使用されます。
たとえば、リストの作成： 結果/関係の表示： ご覧のとおり、句読点の使用は、標準的なプログラミング言語での構文と自然言語での書き込みとの間に一定のトレードオフを提供する、書面で採用された直接的な目的から取られています。
_: 1, 2, .
_:
- 1;
- 2;
- .
module:calc // «calc», «module»
super:module:example$var // «$var» .
コンピューターについて
プログラミング言語について話しているので、標準的なアルゴリズム構造（継承、分岐、ループ）なしでは実行できません。
以下は、自然言語の通常のルールで簡単に説明できます。 1つのステートメントで順次実行する場合、操作と関数呼び出しは、コンマで区切られて順次書き込まれます。それらが異なる文にある場合、それらは次々に同じ方法で書かれます。さらに、段落の書式設定は、テキストの認識と個々のフラグメントの論理的な分離にのみ役立ちます。
条件付きのループ制御構造を作成するときは、すでにキーワードが必要です。しかし、言語に対する当初の要望によれば、アルゴリズム構造を書くための通常の用語を予約することは不可能であるため、キーワードの前にシステム機能のシンボルを示すだけで十分であり、通常の用語をキーワード（制御）ワードと区別することができます。
当然、プログラミング中にこれらの用語を使用できますが、これはまったく必要ありません。特定の自然言語を設定する場合、システム機能とキーワードには特定の用語を割り当て、それらをすでに使用する必要があるため、たとえば次のようになります。
= @goto,
= @label,
= @continue,
=@break ..
そして最後の順番ですが、おそらく本質的に最も重要なのは、関数を呼び出すときにパラメーターを渡すという構造です。完全に自然な構文を目指していると、分析が非常に難しい同じ自然な言語が得られます。
それでも、構文が許可されている場合に括弧を強制的に使用することを回避することで、2つのアプローチを組み合わせることが可能であるように思われます。 ただし 、言い換えると、引数の自然な順序付けのために、関数の括弧とパラメーター間のコンマは省略できます。それらの使用は、構文ではなく、主にターゲットの自然言語によって決定されるべきですが。
: (1, 2(), 3=).
: 1 2 3=.
: ( 2() ).
: 2().
: (2 ).
異議について
私は、プログラマーからのそのような言語の使用に対する十分に根拠のある反対を予見します。その上のプログラムは、通常のコンピューター言語の厳密な正式な構文を使用するよりもはるかに冗長であることがわかります。
したがって、その義務的な特性、つまりプログラムのテキストをある言語から別の言語に変換する機能について思い出させてください。これにより、再定義された自然言語の用語を使用せずに、厳密に正式な構文を使用してプログラムを記述し、ソーステキストを「非プログラマー」の「自然」言語に変換できます。