Pegjs: パラメータ化可能なルールを実装する

これによりかなりの作業量が節約される、または現在不可能なことが可能になる特定のユースケースはありますか？

レベルが引数として渡されるルールを呼び出すことにより、インデントレベルの解析がはるかに簡単になります。

また、純粋なDRYロジックでは、「この文字で区切られたものをエスケープシーケンスなどで区切る」などの場合、ルール（およびそのアクション！）を3回実行するよりも、 delimited('\'', '\\')のようなものを呼び出す方が適切です。 。

もっと明確にすべきだった。 「具体的」とは、「言語Xの文法に取り組んでいて、1つに組み合わせることができる5つのルールがあります。ここにあります」のようなものを探していました。つまり、現実の世界を見たかったのです。ユースケースと実際のコード。 そのことから、この機能がどのような場合に、そして何人の人々に役立つかをよりよく判断することができます。

私はこの機能自体に反対しているので、これを受け取らないでください。 複雑さと実装コストのために、私は一般的に、言語や開発者のごく一部にのみ役立つ機能を実装したくありません。 そしてこの場合、コストは比較的高くなります。

javascriptのパーサーを作成するだけで、 string = delimited_by('\'') / delimited_by('\"')を作成し、後でregexp = delimited_by('/')を作成することができます。

最近、私は自分の言語のパーサーを書いています。 私はPython用に書いたPEGフレームワークにこのようなものがあります：

LeftAssociative(op, subrule): l:subrule rest:(op subrule)* -> a_recursive_function_that_reverses_rest_and_makes_bintrees(l, op, subrule)

そして、私は次のように書くことができます：

...
exp_mult = LeftAssociative(/[\*\/%]/, exp_paren)
exp_add = LeftAssociative(/[\+-]/, exp_mult)

私はC ++とほぼ同じレベルの優先順位を持っているので（そのすべての演算子に加えてさらにいくつか）、でがどれほど役立つか想像してみましょう。 解析式はまだ完成していませんが、すでに12回使用しています。

これは、「インポート」機能と組み合わせると素晴らしいでしょう

require(CommaSeparatedList.pegjs)
require(StringLiteral.pegjs)
require(IntegerLiteral.pegjs)

...

Function
 = name:FuncName "(" args:CommaSeparatedList(Literal)  ")" 

Hash
= "{"   props:CommaSeparatedList(Prop)   "}"

Prop
= Key ":" Literal

Literal =
  StringLiteral / IntegerLiteral

（これはOPの要求よりも少し複雑ですが、それ自体のスレッドを正当化するには近すぎるように見えました。）

私はPEG.jsの助けを借りてR5RSスキームパーサーを構築しています。 コンテキストアウェアな構文解析を必要とする準引用符を除いて、すべてがバラ色です。 テンプレートからオンザフライでルールを生成するためにルールをパラメーター化できると便利で、面倒な後処理を大量に回避できます。 たとえば、簡略化された準引用文法は次のようになります。

    quasiquotation = qq[1]
    qq[n] = "`" qq_template[n]
    qq_template[0] = expression
    qq_template[n] = simple_datum / list_qq_template[n] / unquotation[n]
    list_qq_template[n] = "(" qq_template[n]* ")" / qq[n+1]
    unquotation[n] = "," qq_template[n-1]

ツールに追加することに興味があれば、この機能の開発に貢献することに興味があります。

これを行う主な理由は、コンテキストに敏感な文法をサポートすることです。これは、私が間違っていなければ、最も人気のある言語です（CとPythonにはコンテキスト固有のものがあることは確かです）。 Trevor Jimによると、Haskellも文脈自由ではなく、ほとんどの言語は文脈自由ではないと主張しています。

http://trevorjim.com/haskell-is-not-context-free/
http://trevorjim.com/how-to-prove-that-a-programming-language-is-context-free/

（PEGのように）バックトラックできるパーサーで外部状態を使用することは危険であり、このパーサーで見られるような問題を引き起こす可能性があります。

{   var countCs = 0;
}

start = ((x/y) ws*)* { return countCs }

x = "ab" c "d"
y = "a" bc "e"

c = "c" { countCs++; }
bc = "bc" { countCs++; }

ws = " " / "\n"

上記は、1の正解ではなく2を返します。このような問題は、推論するのが難しい場合があり、潜行性の見つけにくいバグを作成する可能性があり、見つかった場合、回避するのが非常に困難になる可能性があります。 。 PEGによって返されたデータの後処理を行わずにこれを行う方法さえ私にはわかりません。 どういうわけかあなたのパーサー自体がカウントを必要とするなら、それは単に運が悪いです。

現在、（危険なことに）外部状態を使用することが、コンテキストに敏感な文法を解析する唯一の方法です。 パラメータ化されたルールを使用すると、パーサーは無効な状態のリスクを冒すことなくこれを解析できます。

start = countCs:((x<0>/y<0>) ws*)* { return countCs.reduce(function(a,b){return a+b[0];}, 0); }

x<count> = "ab" theCount:c<count> "d" { return theCount; }
y<count> = "a" theCount:bc<count> "e" { return theCount; }

c<count> = "c" { return count++; }
bc<count> = "bc" { return count++; }

ws = " " / "\n"

デビッド、あなたは実際の状況を尋ねました、そしてPythonの空白インデント構文は明らかにここでの例です。 リマ（PEGで作成しているプログラミング言語）で同様の空白インデント構文を実行したいと思います。 しかし、すべてを地獄に吹き飛ばすような無効な状態をうっかり作成してしまう可能性がある場合は、そのようなものを実装したくありません。 Cのx * yのように、コンテキストを必要とする解析構造に名前を付けることができます（x x yまたはyはx型の値へのポインターとして定義されていますか？）。

コンテキストに敏感な文法を解析可能にするには、パラメーター化されたルールにすでに一致した部分式から返された情報を必ず渡す必要があることに注意してください。そうしないと、パーサーは実際にコンテキストを使用できません。 これは、パラメーター化された解析が使用可能であり、以前に一致した式のラベルに（変数として）アクセスできる場合にのみ機能する、Limaについて検討している文字列タイプの実際の例です。

literalStringWithExplicitLength = "string[" n:number ":" characters<n> "]"
number = n:[0-9]* {return parseInt(n.join(''));}
characters<n> = c:. { // base case
  if(n>0) return null; // don't match base case unless n is 0
  else return c;
}
/ c:. cs:characters<n-1> {
  ret c+cs
}

これにより、string [10：abcdefghij]のような文字列を解析できます。 現状では、純粋なPEG.jsではそれを行うことはできません。 あなたは次のようなひどいことをしました：

{ var literalStringLengthLeft=undefined;
}
literalStringWithExplicitLength = "string[" n:specialNumber ":" characters "]"
specialNumber = n:number {
  literalStringLengthLeft = n;
  return n;
}
number = n:[0-9]* {return parseInt(n.join(''));}
characters = c:character cs:characters? {
  return c + cs
}
character = c:. {
  if(literalStringLengthLeft > 0) {
    literalStringLengthLeft--;
    return c;
  } else {
    literalStringLengthLeft = undefined;
    return null; // doesn't match
  }
}

多くのプロトコルには、この種の解析の必要性があります。たとえば、IPv4パケットには、その全長を記述するフィールドがあります。 パケットの残りの部分を適切に解析するには、そのコンテキストが必要です。 IPv6、UDP、およびおそらく他のパケットベースのプロトコルについても同じことが言えます。 TCPを使用するほとんどのプロトコルでも、同じ概念的な文字ストリームを使用して複数の完全に別個のオブジェクトを送信できる必要があるため、このようなものが必要になります。

とにかく、これが優れた機能であるだけでなく、強力な機能であるだけでなく、多くのパーサーに欠けている本当に不可欠な機能（現時点では、PEG.jsを含む）であると思う理由をいくつか挙げていただければ幸いです。 ）。

Pegasus （構文のほとんどをpeg.jsと共有するプロジェクト）は、状態のディクショナリを変更する機能が与えられた#STATE{}式を使用することで、これを解決します。 この状態のディクショナリは、ルールがバックトラックされるときにバックトラックされます。 これにより、重要な空白の解析をサポートできます（詳細については、重要な空白に関するwikiエントリを参照してください）。

また、解析カーソルとともに状態をバックトラックすることにより、ステートフルルールのメモ化も実行できます。

Peg.jsでも同じことが簡単にできると思います。

ルールがバックトラックする場合、ペガサスはバックトラック状態をどのように管理しますか？ 変更されたプログラム状態全体のスナップショットを保持し、元に戻すことができると想像できますが、それはコストがかかります。 変更された変数のみのスナップショットを保持することを想像できますが、ユーザーがそれを指定する必要があり、パーサーの作成が複雑になるか、パーサーがコードの一部で変更されたすべての状態を何らかの方法で把握する必要があります。 これらのどれも理想的に聞こえないので、Pegasusはどのようにそれを行いますか？

理論的には、A。アクションがクロージャにキューイングされ、パーサーが完全に完了した後にのみ実行される場合、およびB.パーサーが完了した後に実行されるため、ルールの一致をキャンセルできない場合、パーサーは無効に実行されたアクションを回避できます。 おそらく、そのスキームは、ペガサスで行われる状態のバックトラックよりも最適でしょうか？

また、無効な状態の問題を修正することは確かに非常に良いことですが、string [10：abcdefghij]のような文字列リテラルに関連して私が提起した表現可能性の問題は解決しませんが、それがどのように機能するかに間違いなく興味があります

プログラム全体の状態をさかのぼることはありません。 状態の不変の辞書を維持します。 現在の状態ディクショナリをカーソルと一緒に保存し、カーソルがバックトラックされるたびに、状態ディクショナリがバックトラックされます。 ディクショナリは#STATE{}アクション以外の場所では不変であり、各状態が変化する直前にコピーされます。

カーソルを進めるたびに追加の変数を設定すると、パフォーマンスがわずかに低下しますが、ステートフルルールをメモ化する機能がこれをはるかに上回ります。 また、状態ディクショナリは不変であるため、変更されるまで共有できるため、これによって大量のメモリが割り当てられることはありません。 たとえば、パーサーに状態がない場合、割り当ては1つだけになります。1つの（空の）状態ディクショナリです。

JavaScriptには（私の知る限り）オブジェクトを不変にする機能はありませんが、それはほとんど安全機能でした。 Peg.jsは、各#STATE{}コードブロックを処理する前に状態ディクショナリをコピーし、カーソルがバックトラックされるたびにそれをバックトラックする必要があります。

わかりました。基本的に、ユーザーは変更する状態を指定する必要があります。 それはいいね。 しかし、それでも、パラメーター化と同じメリットが実際にカバーされているとは思いません。 それ自体が他のことに役立つと思われます。

変数envを使用してアクセスできる環境を提供するフォークを作成しました： https ：//github.com/tebbi/pegjs
これは、上記で提案した#STATE{}オブジェクトと同じです。
これは、（パッケージ）グローバル変数を使用した簡単なハックであり、解析関数が残されるたびに復元されます。 envのコピーは、Object.create（）を使用して実行されます。

これを使用して、Pythonで空白が定義されたブロックを解析する文法の例を次に示します。

{
  env.indLevel = -1
}

block =
  empty
  ind:ws* &{
    if (ind.length <= env.indLevel) return false;
    env.indLevel = ind.length;
    return true;
  }
  first:statement? rest:indStatement*
  {
    if (first) rest.unshift(first);
    return rest;
  }

indStatement =
  "\n" empty ind:ws* &{ return env.indLevel === ind.length; }
  stm:statement
  {return stm; }

statement =
    id:identifier ws* ":" ws* "\n"
    bl:block { return [id, bl]; }
  / identifier

identifier = s:[a-z]* { return s.join(""); }

empty = (ws* "\n")*

ws = [ \t\r]

結果のパーサーの入力例を次に示します。

b:
   c
   d:
       e
   f
g

PEG.jsは、ルールに関するいかなる種類のパラメーターもサポートしていないという印象があります。これは驚くべきことです。 この機能は私にとって非常に重要です。

私が必要としているのは、OPの要求よりも単純です。OPはパラメーターに応じて文法自体を変更したいのですが、少なくとも、ルールに整数を渡す必要があります。 基本的に、次のようなLLLPGルールを変換したいと思います（ PrefixExprは、 -xのようなプレフィックス式、または識別子などの優先順位の高い式です...）：

@[LL(1)]
rule Expr(context::Precedence)::LNode @{
    {prec::Precedence;}
    e:PrefixExpr(context)
    greedy
    (   // Infix operator
        &{context.CanParse(prec=InfixPrecedenceOf(LT($LI)))}
        t:(NormalOp|BQString|Dot|Assignment)
        rhs:Expr(prec)
        { ... }
    |   // Method_calls(with arguments), indexers[with indexes], generic!arguments
        &{context.CanParse(P.Primary)}
        e=FinishPrimaryExpr(e)
    |   // Suffix operator
        ...
    )*
    {return e;}
};
// Helper rule that parses one of the syntactically special primary expressions
@[private] rule FinishPrimaryExpr(e::LNode)::LNode @{
(   // call(function)
    "(" list:ExprList(ref endMarker) ")"
    { ... }
    |   // ! operator (generic #of)
        "!" ...
    |   // Indexer / square brackets
        {var args = (new VList!LNode { e });}
        "[" args=ExprList(args) "]"
        { ... }
    )
    {return e;}
};

私の言語には25の優先順位レベルがあり、これらのルールを使用して、ほとんどすべてを折りたたんで1つのルールで処理しました（ Precedenceは、優先順位を表す2つの整数のラッパーと考えることができます。オペレーター）。 さらに、私の言語には無限の数の演算子（基本的には句読点の任意のシーケンス）があり、演算子の優先順位は解析後に決定されます。 25種類の演算子ごとに個別のルールを使用して、通常の方法で言語を解析することは_技術的に_可能ですが、それは恐ろしい方法です。

また、ここでは、内部ルールFinishPrimaryExprが、囲んでいるルールから渡されたパラメーターを組み込んだ構文ツリーを構築していることがわかります。

それで...パラメータをPEG.jsルールに渡す方法はありますか？

+1！ 私の場合、構文のパーサーを生成したいだけです。ここで、いくつかの区切り文字はグローバルに構成可能です。 この場合、述語と組み合わせた任意の式に一致することで区切り文字リテラルを置き換えることでこれを実現できますが、すべてを変数に置き換えることができれば、はるかにエレガントになります（さらに効率的になります）。

+1、これが近い将来に実装されるのを見るチャンスはありますか？

別のユースケース。 これは、 javascript.pegjsの例からのものです。

(...)

RelationalExpression
  = head:ShiftExpression
    tail:(__ RelationalOperator __ ShiftExpression)*
    { return buildBinaryExpression(head, tail); }

RelationalOperator
  = "<="
  / ">="
  / $("<" !"<")
  / $(">" !">")
  / $InstanceofToken
  / $InToken

RelationalExpressionNoIn
  = head:ShiftExpression
    tail:(__ RelationalOperatorNoIn __ ShiftExpression)*
    { return buildBinaryExpression(head, tail); }

RelationalOperatorNoIn
  = "<="
  / ">="
  / $("<" !"<")
  / $(">" !">")
  / $InstanceofToken

(...)

  (...)
  / ForToken __
    "(" __
    init:(ExpressionNoIn __)? ";" __
    test:(Expression __)? ";" __
    update:(Expression __)?
    ")" __
    body:Statement
  (...)

(...)

これらすべての...NoInルール（およびそれらがたくさんあります）は、単にfor inステートメントのために必要です。 これに対するはるかに優れたアプローチは、次のようなものではないでしょうか。

(...)

RelationalExpression<allowIn>
  = head:ShiftExpression
    tail:(__ RelationalOperator<allowIn> __ ShiftExpression)*
    { return buildBinaryExpression(head, tail); }

RelationalOperator<allowIn>
  = "<="
  / ">="
  / $("<" !"<")
  / $(">" !">")
  / $InstanceofToken
  / &{ return allowIn; } InToken
    {return "in";}

(...)

  (...)
  / ForToken __
    "(" __
    init:(Expression<false> __)? ";" __
    test:(Expression<true> __)? ";" __
    update:(Expression<true> __)?
    ")" __
    body:Statement
  (...)

(...)

これは、たとえば、JavaScriptの文法を指定する方法と非常によく似ています。https ：//tc39.github.io/ecma262/#prod -IterationStatement（ ~Inに注意してください）

私が現在開発している言語には、この正確な問題があります。特定の時点でのみ一部のルールを無効/有効にしたいのです。 JavaScript文法の場合のように、影響を受けるすべてのルールを複製することは非常に控えたいと思います。

ルールを複製せずにこれを達成するための代替方法はありますか？

+1、これが近い将来に実装されるのを見るチャンスはありますか？

この問題にはマイルストーンが割り当てられています（1.0.0以降）。 PEG.jsの現在のバージョンは0.10.0です。 明らかに、1.0.0以降の問題は、1.0.0をリリースした後に処理されます。これは、ロードマップに従って、0.11.0をリリースした後のある時点で発生します。

これはあなたの質問に答えるはずです。 プロセス全体を加速する最善の方法は、 0.11.0および1.0.0を対象とした問題を支援することです。

ルールを複製せずにこれを達成するための代替方法はありますか？

考えられる方法は、状態を手動で追跡してから、セマンティック述語を使用することです。 ただし、このアプローチにはバックトラッキングの問題があるため、お勧めしません（つまり、ルールの複製と手動の状態追跡のどちらかを選択する場合は、複製を選択します）。

パーサーに渡すことができる引数には、次の2つのタイプがあります。

1. 値。 Python、Nim、Haskell（および別の方法でScheme）などの言語の文法は、ツリー内の式の「深さ」に依存します。 正しい文法を書くには、どういうわけかこのコンテキストを渡す必要があります。
2. パーサー。 leftAssociative(element, separator) 、 escapedString(quote) 、 withPosition(parser)はその良い例です。

引数がパーサーであるか値であるかを何らかの方法でマークする方法があるはずです。 正しいアプローチを見つけようとしたとき、コンテキストにグローバル変数を使用することになりましたが、それは明らかに行き止まりです。 誰かがそれについて何か考えを持っていますか？

マクロはどうですか？

与えられた：

Add <Expression, Add>
  = left:Expression _ '+' _ right:Add
    { return { type: 'add', left, right } }
  / Expression

いつ：

  = Add <MyExpression, MyAdd>

MyExpression
  = [0-9]+

それで：

  = left:MyExpression _ '+' _ right:MyAdd
    { return { type: 'add', left, right } }
  / MyExpression

MyExpression
  = [0-9]+

これにより、ボトムアップからルールを構築できます：smirk：

同意します。開発者がこの機能を追加することをお勧めします:)

私が書いている更新されたJavaScript文法にはこの機能が本当に必要なので、これは私のウィッシュリストの上位にあります。 それを試してみて、それがどのように機能するかを見ていきます。

@samvv非常に異なるルートからこれに遭遇しましたが、まだスレッド全体を読んでいません。
ただし、ここで参照した＃572では、パラメーター化されたルールをシミュレートできる手法を示しています。

つまり、本質的には、関数を中間の解析結果として返します。

その「トリック」は決して私の発明ではなく、おそらくあなたの目的にはかなり不格好だと思います。 しかし、それはあなたにとっての回避策かもしれません。 私は「v1.0以降」までを意味します... :)

@meislかっこいい、ヒントをありがとう！ 時間があれば試してみます。

@samvvああ、ああ...私はかなり重要な何かを見落としているのではないかと思います：

パラメータ化されたルールが必要かどうかはかなり違います

• パラメータに依存する値のみを生成できます
• または（また）解析の決定をパラメータに依存させる

私が提案したのは前者だけに役立ちますが、後者はOPの実際の問題です...
そのために残念。

ただし、後者の場合でも、さらに不格好ではありますが、回避策があります。
そして、「依存決定」の部分は、関数を返すこととは何の関係もありません...

https://pegjs.org/onlineで試してみるための例を追加します

基本的な考え方は、グローバル状態を使用して現在の「ターミネータ」を記憶することです。 確かに、それはかなりのハックであり、繰り返しです。
ただし、さらに別の区切り文字を追加すると、 |は、 strにもう1つ追加することを意味します。

  / (t:'|' {term = t}) c:conts t:.&{ return isT(t) }  { return c }

これは、1つの文字|だけが他の文字と異なります。

{
  var term;
  function isT(ch) { return ch === term }
  function isE(ch) { return ch === '\\' }
}
start = str*

str
  = (t:'\"' {term = t}) c:conts t:.&{ return isT(t) }  { return c }
  / (t:'\'' {term = t}) c:conts t:.&{ return isT(t) }  { return c }

conts
  = c:(
        '\\' t:.&{ return isT(t) || isE(t) } { return t }
      /      t:.!{ return isT(t)           } { return t }
    )*
    { return c.join('') }

...入力について

• "abc" -> ["abc"]
• "a\"bc" -> ["a\"bc"]
• "a\\bc" -> ["a\bc"]
• "a\\b\"c"'a\\b\'' -> ["a\b\"c", "a\b'c"]

ps：それは実際には手で書きたいものではありません。 しかしねえ、それがあなたのために生成されると想像してください...私は原則としてそれがどのように行われると思います。

@ceymard -10年後だと思いますが、これが＃36とどう違うのか気になります

うわー、覚えるのに少し時間がかかりました。 10年 ！

このPRでは、ルールは引数を取り、パラメーター化できます。 これは、類似しているが異なる規則を繰り返さないようにするために、文法自体によって使用されることを意図しています。

＃36では、規則は文法自体の外で指定されています。 したがって、文法自体がパラメータ化されます。

範囲は違うと思いますが、文法自体がルールであり、同じ問題であると言えるかもしれません。 ＃36はおそらくAPIのわずかな変更を意味しますが、このPRはそうではないので、そうではないと思います。

したがって、C ++ ishの用語を非常に誤った方法で悪用するには、前者はテンプレート静的であり、後者はコンストラクター呼び出しですか？

はい、このアナロジーはある程度機能すると思います。

説明お時間をいただきありがとうございます

おそらく10年後に別の質問があります。 良い2020年代を

これは、パーサー定義の冗長性を取り除くのに非常に役立ちます。 私は意図的に非常にリラックスしたカスタム文法を持っており、いくつかのルールはわずかに異なるコンテキストで適用する必要があります。