2017-06-14 4 views
0

文法を解析する際に、正規表現として使用できる文法と一致させるためにRegExを使用するか、現在のパーサ設計を排他的に使用する必要がありますか?したがって、文法(例えば再帰下降構文解析又はアドホックパーサーなど)字句解析のいくつかのタイプを使用して一致する必要があるであろうインタプリタやコンパイラのパーサで正規表現を使用する必要がありますか?

object ::= '{' '}' | '{' members '}'; 
members ::= pair | pair ',' members; 
pair ::= string ':' value; 
array ::= '[' ']' | '[' elements ']'; 
elements ::= value | value ',' elements; 
value ::= string | number | object | array | 'true' | 'false' | 'null'; 

例えば、JSONためのEBNF文法のように表すことができます。しかし、(例えば数など)の値の一部のための文法は数については、この正規表現パターンのような規則的な言語として表すことができる。

-?\d+(\.\d+)?([eE][+-]?\d+)? 

この例を考えると、一方が再帰下降JSONパーサを作成していると仮定すると..番号がマチェットでなければならないRegExを使用して簡単に一致させることができるため、RegExを使用して一致させる必要がありますか?

+0

入れ子になっていればまともなパーサを使用したいと思います。個々のコンポーネントは正規表現を使用して文字(一般にクラスを持つ)を一般化することができます。 – sln

答えて

0

これは非常に幅広く意見の多い質問です。したがって、私の知る限りでは、通常、パーサーが可能な限り高速で、メモリを最小限に抑えることが望まれます(特に、オンデマンドで解析する必要がある場合)。

RegExは確かに仕事をしますが、核兵器で飛ぶようなものです!

、多くのパーサーは、文字列ポインタを利用し、不変のフィールドを持つJavaなどの高級言語によって引き起こされるオーバーヘッドを回避するために、Cのような低レベル言語、ガベージコレクタ、...

に書かれている理由です

一方、これはユースケースに大きく依存し、一般的な方法で真に答えられることはありません。開発者がRegExとパーサーのパフォーマンスを使い分ける利便性とのトレードオフを考慮する必要があります。

通常、構文エラーがどこにあるのか、どのタイプのエラーであるのかをパーサに示すことをお勧めします。正規表現を使用すると、単純に一致しないため、適切なエラーメッセージを表示するために停止した理由を見つけるのが難しくなります。旧式のパーサを使用する場合、構文エラーが発生するとすぐに構文解析を停止することができ、一致しなかった箇所と正確な箇所を正確に知ることができます。

あなたの特定のケースでは、JSONの解析とRegExの使用は、おそらく高水準言語を使用していると思います。そのため、多くの実装では言語のネイティブ解析を使用しています。区切り文字を使用して値(文字列、数値など)を選択し、プログラミング言語が数値解析の例外を投げるようにしてください。

関連する問題