1

リソース API 用の簡単なスクリプトを作成しようとしています。リソース API は、主に構造化された方法でゲーム リソースを作成します。私が望むのは、リソースが必要になるたびに C++ プログラムを作成することなく、この API を処理することです。そこで、私たち (私と大学の講師) は、リソース ファイルを毎回コンパイルせずに作成/編集するための簡単なスクリプトを作成することにしました。GUI プログラムではなくコマンド ライン インターフェイスが必要であるという無関係な要素が他にもいくつかあります。

とにかく、ここにスクリプトのサンプルがあります：

<path>.<command> -<options>
/Graphics[3].add "blabla.png"

このスクリプト言語を設計したのは私ではなく、API の所有者です。「.」より前の部分 ご想像のとおり、「。」の後のパスと部分です。は実際のコマンドといくつかのオプション、フラグなどです。最初のステップとして、字句解析器とパーサーに関する情報を検索するときに使用できると思ったので、左側の部分の文法を作成してみました。問題は、言語の解析とプログラミングに関しては経験が浅く、それが正しいかどうかわからないことです。左辺の例と文法を次に示します。

dir -> '/' | '/' path
path -> object '/' path | object
object -> number | string '[' number ']'

この文法が混乱する可能性がある場合の表記は、わかりません。5 つの異なる可能性があります。

String
"String"
Number
String[Number]
"String"[Number]

「/」記号で始まる必要があり、それが唯一の記号である場合は、それをルートとして受け入れます。

今私の問題は、このスクリプトを字句解析するにはどうすればよいですか? 特別な方法はありますか？私の語彙アナライザーは何をすべきか、何をすべきでないか (いくつかの語彙アナライザーは、ある程度まで構文解析も行っていると読んでいます)。文法などは技術的に適切だと思いますか? どのような解析方法を使用すればよいですか (再帰降下、LL など)? 私はそれを技術的に適切な作品にしようとしています。営利目的ではないので時間があり、字句解析と構文解析をよりよく学ぶことができます。パーサー ライブラリを使用したくありません。

4

1 に答える 1

3

字句解析器がすべきこととすべきでないことは?

そうすべき：

  • トークンを認識する
  • 無視できる空白とコメントを無視する (そのようなものがある場合)
  • オプションで、意味のあるエラー メッセージを生成するために、ソースの場所を追跡します。

このような単純な言語では非常に魅力的ですが、入力の解析を試みるべきではありません。

私が見る限り、次のトークンがあります。

  • 句読点: /、.、線形空白、改行
  • 数字
  • 引用符で囲まれていない文字列 (「atoms」または「id」と呼ばれることが多い)
  • 引用符で囲まれた文字列 (おそらく、引用符で囲まれていない文字列と同じトークン タイプ)

構文が何であるかはわかりません-optionsが、それにはさらに多くの可能性が含まれる可能性があります。

トークンとして返すlinear-white-space(つまり、タブとスペースのみで構成されるシーケンス) を選択することには、やや疑問があります。特に、行頭や行末など、空白が無視できる場所がおそらくあるため、文法がかなり複雑になります。しかし、パス内に空白を許可したくないという直感があり、コマンド名とその引数の間にそれを要求する予定です。つまり、次を禁止します。

/left /right[3] .whimper "hello, world"
/left/right[3].whimper"hello, world"

しかし、多分私は間違っています。たぶん、あなたは両方を喜んで受け入れます。両方を受け入れると、線形空白を完全に無視できるため、それはより簡単になります。

ところで、経験上、改行を使用してコマンドを区切るのは扱いにくい場合があります。遅かれ早かれ、行全体を表示するために追加のモニターを購入する必要がないように、コマンドを 2 行に分割する必要があります。継続する行の最後の文字としてa を置くという規則 (特に bash や C プリプロセッサで使用される)\は可能ですが、厄介なバグ (の後に目に見えないスペースがある\ため、実際にはそれが妨げられるなど) につながる可能性があります。行を継続します）。

ここから先は、100%個人の意見であり、無料で提供されています。だから、その価値のためにそれを取ります。

私はそれを技術的に適切な作品にしようとしています。営利目的ではないので時間があり、字句解析と構文解析をよりよく学ぶことができます。パーサー ライブラリを使用したくありません。

私の意見では、ここに矛盾があります。または、おそらく 2 つの矛盾。

技術的に適切な作業では、標準ツールを使用します。少なくとも語彙ジェネレーターとおそらくパーサージェネレーター。適切に使用すれば、ツールに提供される語彙的および文法的記述が実際の言語を正確に文書化し、ツールが目的の言語が実際に認識されるものであることを保証するためです。その場しのぎのコードを書くことは、単純な字句認識エンジンや再帰的降下パーサーでさえ、エレガントであるにもかかわらず、自己文書化が少なく、保守性が低く、正確性の保証が少なくなります。したがって、ベスト プラクティスは「標準ツールを使用する」ことです。

第二に、アドホックなレクサーとパーサーを書くことが語彙と構文解析の理論を理解するのに役立つというあなたのインストラクターに同意しません (あなたのコメントに基づいて彼らの提案を正しく理解しているなら)。実は逆効果かもしれません。理論的にも実際的にも信じられないほど洗練されたボトムアップ構文解析は、手で書くことはほとんど不可能であり、読むことはまったく不可能です。その結果、多くのプログラマーは、コードを理解しているため、再帰降下または Pratt パーサーを使用することを好みます。ただし、このようなパーサーは、ボトムアップ パーサー (特に、完全に一般的な GLR または Earley パーサー) ほど強力ではなく、それらを使用すると、不必要な文法上の妥協につながります。

正規表現を理解するために正規表現ライブラリを作成する必要はありません。ライブラリは厄介な実装の詳細を抽象化し (そしてそれらはたくさんあり、実際には厄介です)、正規表現の作成と使用の本質に集中できるようにします。

同様に、C でプログラミングする方法を理解するためにコンパイラーを作成する必要はありません。Cの基礎を十分に理解したら、それが機械語コードにどのように変換されるかを理解することで (おそらく) 理解を深めることができますが、コンパイラー作成のキャリアを計画していない限り、あいまいな最適化アルゴリズムの詳細を知っていても、優れたプログラマーにはなりません。または、少なくとも、彼らはあなたの議題の最初ではありません.

同様に、正規表現を本当に理解したら、ライブラリを書くのが面白いと思うかもしれません。信じられないほどイライラして、数か月のハードワークの後にあきらめるかもしれません。いずれにせよ、既存のライブラリをより高く評価するでしょう。ただし、最初に既存のライブラリの使用方法を学習してください。

パーサージェネレーターも同様です。プログラミング言語のアイデアを正確で実装可能なものに変換する方法を学びたい場合は、パーサー ジェネレーターの使用方法を学びます。構文解析の理論を習得して初めて、低レベルの実装に焦点を当てることを考えるべきです。

于 2013-07-11T16:37:48.123 に答える