Pegjs: シーケンスからの単一の戻り値を示す簡潔な方法を提供します

これが一般的な問題であることに同意します。 しかし、それを解決する価値があるかどうかはわかりません。 言い換えれば、それが十分に頻繁に発生するかどうか、そしてそれがソリューションを実装することによってPEG.jsに複雑さを追加することを正当化するのに十分な苦痛を引き起こすかどうかはわかりません。

この問題は未解決のままにして、1.0.0以降の検討対象としてマークします。

同意しました。 これを1.0で見たいです。 しかし、@構文にはそれほど熱心ではありません。 IMHOの方が良い考えは、これを行うことです。「トップレベル」のラベルが1つしかない場合は、そのラベルを暗黙的に返します。 したがって、代わりに：

rule = space* a:(text space+ otherText)+ newLine* { return a; }

あなたが得る：

rule = space* a:(text space+ otherText)+ newLine*

また、ラベルが特に意味のあるものでない場合は、次のことも許可します。

rule = space* :(text space+ otherText)+ newLine*

したがって、ラベル名は完全にスキップしてください。

@mulderr @演算子の方が優れていると思います。

@の+ 1-これは私のコード全体で何度も繰り返されます。

これを行うための簡潔な方法については+1。

この痛みは、ES6が矢印関数を使用して対処するJSの冗長なfunction構文の痛みに似ているようです。 たぶん、似たようなものをここで使用できますか？ 何かのようなもの：

rule = (space* a:(text space+ otherText) newLine*) => a

これはかなり柔軟性があり、まだ明示的であり（ @wildeyesの懸念）、構文と実装の両方で基盤となるJSに

私は少し次のようなものを描いてきました：

additive = left:multiplicative "+" right:additive {= left + right; }

ブロックの最初の非空白文字としての= （文字の選択について自由に議論してください）がreturnに変換される場合。

これは完全な式でも機能し、変換パスで可能になるはずです。

連絡あった？ なぜadditive = left:multiplicative "+" right:additive { => left + right }ないのですか？

矢印関数がどのように機能するかを考えると、確かに直感的に感じるでしょう（ (left, right) => left + right ）。

実際、parser.pegjsファイルには、この機能によって改善される場所の例がかなりあります。

例えば：

  = head:ActionExpression tail:(__ "/" __ ActionExpression)* {
      return tail.length > 0
        ? {
            type: "choice",
            alternatives: buildList(head, tail, 3),
            location: location()
          }
        : head;
    }

シーケンス内のActionExpressionの位置に直感的にリンクされていないbuildList呼び出しのマジックナンバー3のため、壊れやすいです。 buildList関数自体は、2つの異なる操作を組み合わせることによって複雑になります。 @式とes6spread構文を使用することにより、これはよりクリーンになります。

  = head:ActionExpression tail:(__ "/" __ @ActionExpression)* {
      return tail.length > 0
        ? {
            type: "choice",
            alternatives: [head, ...tail],
            location: location()
          }
        : head;
    }

これはほとんど単なるシンタックスシュガーなので、parser.pegjsのActionExpressionを変更するだけで、この機能をパーサーに追加することができました。

  = ExtractSequenceExpression
  / expression:SequenceExpression code:(__ CodeBlock)? {
      return code !== null
        ? {
            type: "action",
            expression: expression,
            code: code[1],
            location: location()
          }
        : expression;
    }

ExtractExpression
  = "@" __ expression:PrefixedExpression {
      return {
        type: "labeled",
        label: "value",
        expression: expression,
        location: location()
      };
    }

ExtractSequenceExpression
  = head:(__ PrefixedExpression)* _ extract:ExtractExpression tail:(__ PrefixedExpression)* {
      return {
        type: "action",
        expression: {
          type: "sequence",
          elements: extractList(head, 1).concat(extract, extractList(tail, 1)),
          location: location()
        },
        code: "return value;",
        location: location()
      }
    }

@表記を使用してparser.pegjsがどのように単純化されるかを示す要点をチェックインしました。

@表記によりシーケンスから目的の値を簡単に抽出できるため、extractOptional、extractList、およびbuildList関数は完全に削除されました。

https://gist.github.com/krisnye/a6c2aac94ffc0e222754c52d69e44b83

@krisnyeさらに多くのシンタックスシュガーがあった場合の外観は次のとおりです。

https://github.com/polkovnikov-ph/newpeg/blob/master/parse.np

この構文機能に::と#組み合わせを使用することを考えています（ ＃545の私の説明/理由を参照し

• ::バインディング演算子
• #展開演算子

// this is imported into grammar
class List extends Array {
  constructor() { this.isList = true; }
}

// grammar
number = _ ::value+ _
value = ::int #(_ "," _ ::int)* { return new List(); }
int = $[0-9]+
_ = [ \t]*

• ルールのルートシーケンスで、 ::は、ルールの結果として式の結果を返します。
• ネストされたシーケンスでは、 ::は、シーケンスの結果としてネストされた式の結果を返します。
• 複数の::が使用されている場合、マークされた式の結果は配列として返されます
• ::を含むネストされたシーケンスで#が使用されている場合、結果は親の配列にプッシュされます
• ルールに:: / #とともにコードブロックがある場合は、最初にそれを実行してから、結果pushメソッドを使用します

これらのルールに従って、上記の例で生成されたパーサーに09 , 55, 7を渡すと、次のようになります。

result = [
    isList: true
    0: "09"
    1: "55"
    2: "7"
]

result instanceof Array # true in ES2015+ enviroments
result instanceof List # true

ルールのルートシーケンスで、::は式の結果をルールの結果として返します
ネストされたシーケンスでは、::はネストされた式の結果をシーケンスの結果として返します

なぜこれらは別々なのですか？ 「シーケンスの::がシーケンスの引数結果の結果になる」だけではないのはなぜですか？

複数の::が使用されている場合、マークされた式の結果が配列として返されます。

それは悪い考えです。 この場合はむしろ救済したいと思います。 複数のタイプの値を組み合わせて配列にする意味はありません。 （それはタプルになりますが、JSではほとんど役に立ちません。）

シーケンスで＃が使用されている場合、結果は親の配列に配列＃連結されます

今ではそれは恐ろしい考えです。 これは明らかに、無関係な{ return xs.push(x), xs }を取り除くための応急修理です。 このような特殊なケースを作成しても、パラメーター化されたルールを使用して一般的な方法で解決できるため、意味がありません。 演算子に使用する単一文字シーケンスはそれほど多くないので、それらを無駄にするべきではありません。

ルールに:: /＃とともにコードブロックがある場合は、最初にそれを実行してから、結果プッシュメソッドを使用します

それで、 f = ::"a" { return "b" }は結果として["a", "b"]を持つべきですか？

09を通過します。 55：上記の例で生成されたパーサーの7は、次のようになります。

そうではなく、 .または:については言及されていません。 記述された振る舞いがどのように結果を生み出すのかもわかりません。

数値= _ ::値+ _

また、それは_使用方法ではありません。 トークンの右側または左側に配置され、文法用に1回選択されます。 右側の場合、メインルールも_開始する必要があり、その逆も同様です。

start = _ value
value = ::int #("," _ ::int)* { return new List(); }
number = ::$[0-9]+ _
_ = [ \t]*

JavaScriptの例で実装されたクラスの例（実際の実装を意図したものではありません）：

ClassMethod
  = head:FunctionHead __ params:FunctionParameters __ body:FunctionBody {
      return {
        type: "method",
        name: head[ 1 ],
        modifiers: head[ 0 ],
        params: params,
        body: body
      };
    }

// `::` inside the zero_or_more "( ... )*" builds an array as we want,
// so this rule returns `[FunctionModifier[], Identifier]` as expected
MethodHead = (::MethodModifier __)* ("function" __)? ::Identifier

// https://github.com/tc39/proposal-class-fields#private-fields
MethodModifier
  = "#"
  / "static"
  / "async"

FunctionParameters
  = "(" __ head:FunctionParam tail:(__ "," __ ::FunctionParam)* __ ")" {
      // due to `::`, tail is `FunctionParam[]` instead of `[__, "", __, FunctionParam][]`
      return [ head ].concat( tail );
    }
    / "(" __ ")" { return []; }

FunctionParam
  = name:Identifier value:(__ "=" __ ::Expression)? {
      return { name, value };
    }

FunctionBody = "{" __ ::SourceElements? __ "}"

なぜこれらは別々なのですか？ シーケンスの::で、シーケンスの引数の結果が得られないのはなぜですか？」

それは同じことではありませんか？ MethodHead 、 FunctionParam 、 FunctionBodyなどのさまざまなユースケースの結果を簡単に理解できるように、より明確にしただけです。

複数のタイプの値を組み合わせて配列にする意味はありません。 （それはタプルになりますが、JSではほとんど役に立ちません。）

AST（生成されたパーサーの最も一般的な結果）を構築する場合、私の意見では、次のように書く代わりに、 MethodHeadようなユースケースを単純化します。

MethodHead
  = modifiers:(::MethodModifier __)* ("function" __)? name:Identifier {
      return [ modifiers, name ];
    }

よく考えてみると、ユースケースは単純化されますが、開発者が（文法の実装方法やアクションによる結果の処理方法のいずれかで）間違いを犯す可能性もあるので、これを置くと思いますmultipleSingleReturns （デフォルト： false ）のようなオプションの背後にあるユースケースは、ここでの最善の行動です（この機能が実装されている場合）。

シーケンスで＃が使用されている場合、結果は親の配列に配列＃連結されます

今ではそれは恐ろしい考えです。 これは明らかに、無関係な{return xs.push（x）、xs}を取り除くための応急修理です。

また、 FunctionParametersような、より一般的なユースケースでも役立ちます。

// should always return `FunctionParam[]`
FunctionParameters
  = "(" __ ::FunctionParam #(__ "," __ ::FunctionParam)* __ ")"
  / "(" __ ")" { return []; }

パラメータ化されたルールを使用して一般的な方法で解決できます

後でどのように進めるかまだわからないので、パラメーター化されたルールの前に単一の戻り値を実装する必要があると考えています（テンプレートを使用するのは好きですが、 rule < .., .. > = ..を使用すると多くのノイズが追加されるようですPEG.jsの文法なので、構文を少し変更してより適切に適合させることを考えています）が、それは別の問題です。

演算子に使用する単一文字シーケンスはそれほど多くないので、それらを無駄にするべきではありません。

それは本当ですが、機会がこのようになっているときにそれらを使用しない場合、それは同じように悪いことです。

#は、前処理ディレクティブを実装する一部の言語で展開演算子として使用されていることを思い出した後、このユースケースに使用することを考えました。これは、基本的にこのユースケースがここでカバーしていることです。

それで、 f = ::"a" { return "b" }は結果として["a", "b"]を持つべきですか？

いいえ、コードブロックはパーサーによってpushメソッドを含む配列のようなオブジェクトを返すことが期待されているため（したがって、 f = ::"a" { return [ "b" ] } [ "b", "a" ]は結果としてpushSingleReturnsようなオプションの背後にあるかどうかを理解する方が良いでしょうか？ このオプションがfalse （デフォルト）の場合、単一の戻り値を含むシーケンスの後にコードブロックがあると、エラーがスローされます。

09を通過します。 55：上記の例で生成されたパーサーの7は、次のようになります。

そうではなく、 .または:については言及されていません。

申し訳ありませんが、それは私が与えられた例を書き直したときに残された間違いでした。

また、それは_使用方法ではありません。 トークンの右側または左側に配置され、文法用に1回選択されます。 右側の場合、メインルールも_開始する必要があり、その逆も同様です。

これは本当に好みの問題だと思います：smile ：、この例を理解する方が簡単だったと思いますが：

number = _ ::value+ EOS
...
EOS = !.

記述された振る舞いがどのように結果を生み出すのかもわかりません。

この更新されたコメントは、私が言おうとしていることを理解するのに役立ちますか？そうでない場合は、あなたは何を理解していませんか。

私は@ polkovnikov-phに同意します。場所によって提供される変更は非常に明白ではなく、追加のエラーの原因にすぎないということです。

シーケンスで＃が使用されている場合、結果は親の配列に配列＃連結されます

文法start = #('a')何を返す必要がありますか？ 私が理解している限り、彼は配列をフラット化するためのシンタックスシュガーをどのように考えましたか？ この演算子は必要ないと思います。 最も明白な使用法（区切り文字を使用したメンバーリストの式）については、特別な構文を作成することをお勧めします（＃30と私のフォークhttps://github.com/Mingun/pegjs/commit/db4b2b102982a53dbed1f579477c85c06f8b92e6を参照）。

ルールに:: /＃とともにコードブロックがある場合は、最初にそれを実行してから、結果プッシュメソッドを使用します

非常に明白でない行動。 文法ソースのアクションは式の後に配置され、通常は式の解析後に呼び出されます。 そして突然、どういうわけかそれらは解析の前に呼び出され始めます。 ラベルはどのように動作しますか？

あなたがなんとか説明した残りの3つのポイントは、彼らの明確な感覚が逃げ始めました。 @ polkovnikov-phが、最初のケースと2番目のケースを区別するために説明に含まれている理由をどの程度正確に記録しましたか？ 2つの単純なルールのみが実行されます。

1. :: （率直に言って、私はこの文字の選択が好きではない、ノイズが多すぎる）式がsequenceこの文字でマークされたノード要素が戻るという事実につながる前に
2. シーケンス内でそのような要素が1つだけの場合はその結果が返され、そうでない場合は結果の配列が返されます。

例：

start =   'a' 'b'   'c'; // => ['a', 'b', 'c']
start = ::'a' 'b'   'c'; // => 'a'
start = ::'a' 'b' ::'c'; // => ['a', 'c']

大きな例では、 ::から予想される内容を正確に説明しており、疑わしいユースケース（ # 、いくつかの:: ）については説明していません。

それは同じことではありませんか？

それが私が求めてきたものです。 一般的な方法での説明は、読者にそれが本当に同じものであることを確信させるので、通常はより有用です。 ご説明ありがとうございます。 :)

私の意見では、MethodHeadのようなユースケースを簡素化するでしょう

しかし、代わりにオブジェクトを作成してみませんか？ 表記にはmodifiers:とname:があり、結果のJSオブジェクトのままにしておくと、すばらしいでしょう。

また、開発者が間違いを犯す可能性もあります（文法の実装方法、またはアクションによる結果の処理方法のいずれか）。

当初、私はこれについて書くつもりでしたが、その後、私には十分な難しい議論がないと判断しました。 同じレベルのシーケンスで複数の::を許可したくありません（フラグがあっても）。

また、FunctionParametersのような、より一般的なユースケースで次のように記述したほうがよい場合にも役立ちます。

しかし、それは同じことです。 本当に素晴らしい構文はinter(FunctionParam, "," __)で、

inter a b = x:a xs:(b ::a)* { return xs.unshift(x), xs; }

ルール<..、..> = ..PEG.jsの文法に多くのノイズを追加するようです

人々は<...>が型に使用されることを期待していますが、この場合、引数は型ではありません。 最良の方法は、余分な文字をまったく含まないHaskellの方法です（上記のinter参照）。 ;を省略したPEG.js文法でこれがどのように相互作用するかはわかりません。 f a b = ...が（部分的に）前の行に含まれる場合があります。

前処理ディレクティブを実装する一部の言語で展開演算子として使用されます

はい、でも私はそれを賢く使いたいです。 配列に対して提案されたpushアクションの代わりに、オブジェクトに対するObject.assignアクションとして、または空の文字列（ eps ）に一致するものとして使用しますが、その議論。 たとえば、

f = type:#"ident" name:$([a-z]i [a-z0-9_]i+)

入力"abc"に対して{type: "ident", name: "abc"}を返します。

いいえ、コードブロックは、プッシュメソッドを含む配列のようなオブジェクトを返すことがパーサーによって期待されているためです（したがって、f = :: "a" {return ["b"]} return ["b"、 " a "]結果として）、

O_O

これは本当に好みの問題だと思います

それだけでなく、パフォーマンスも。 すべてのトークンの両側に_がある場合、空白文字シーケンスは末尾の文字シーケンスとのみ一致し、先行する_は何も一致しません。 parse$_への追加の呼び出しに_が2倍多いため、コードは長くなります。

@Mingun私は@futagozaは、設計空間を探求すると思います。 それは良いことです、特にそれが公開されていて、私たちが反対する機会がある場合は:)

主なことは、「なぜ」と言うのではなく、「いいえ！そんなことはありません！」と言うことです。

f = type:#"ident" name:$([a-z]i [a-z0-9_]i+)は、入力"abc"に対して{type: "ident", name: "abc"}を返します。

いいえ、ハハ。 その構文は_wayyy_あまりにも魔法です。

最初に提案された@演算子は、現状のままで

sequence
    = first:element rest:(whitespace next:element {return next;})*
    {
        return [first].concat(rest);
    }
    ;

特にそれよりも複雑な場合は、何度も何度も入力するのが面倒です。

ただし、 @演算子を使用すると、上記は単純になります。

sequence = first:element rest:(whitespace @element)* { return [first].concat(rest); };

https://github.com/pegjs/pegjs/issues/235#issuecomment -66915879またはhttps://github.com/pegjs/pegjs/issues/235#issuecomment -67544080のいずれかを使用すると、さらに次のようになり

sequence = first:element rest:(whitespace @element)* => [first].concat(rest);
/* or */
sequence = first:element rest:(whitespace @element)* {=[first].concat(rest)};

...最初のものは私が非常に部分的です。

これは、簡単に達成できる下位互換性のある変更のようです（誰かがすでにそれを行っているようです）。

実際、私が間違っていなければ、それは単なる小さなバンプである可能性があります。 0.11.0@futagozaについて考えることがあるかもしれません。

これをマスターに追加しました。 マルチプラッキングに::を使用し、シングルプラッキングに@を使用することを計画していましたが、ラベル付きの::を使用すると、非常に見苦しく混乱するように見えたので、そのアイデアをぶら下げました🙄

私はしばらく前にこれを自分で実装し始めましたが、今までそれを削除し（代わりに＃579を実行する必要があります😆）、バイトコードジェネレーターをMingunの実装に基づいています（https://github.com/Mingun/pegjs/commit/1c1c852bae91868eaa90d9bd9f7e4f722aa6435e ）

ここで試してみることができます： https ：//pegjs.org/development/try（オンラインエディターですが、PEG 0.11.0-devを使用しています）

聖なるターンアラウンドタイム、バットマン。 素晴らしい仕事@futagoza 、これは完璧に機能しました-非常に感謝しています。 これはすでにnpmのdevタグにリリースされましたか？ 私はそれでテストを始めたいです。

基本的な文法で試してみたい人は、この子犬をそこに入れて、 "abcd"ような入力をしてください。

foo
    = '"' @$bar '"'
    ;

bar
    = [abcd]*
    ;

これはすでにnpmのdevタグにリリースされましたか？

https://www.npmjs.com/package/pegjs/v/0.11.0-dev.325

こんにちは、これはes6があれば消える問題のひとつであり、それ以降es6に追加された他のものにはこれらの文字が必要です。 すでに実行できることに対して演算子を追加することは、非常に逆効果です。

このチケットはマージされました

pattern:Pattern init:(_ "=" _ <strong i="7">@a</strong>:AssignmentExpression)?

誰もが本質的に理解し、パーサーの他の部分が終了すると無料で提供されるes6の同じことは次のとおりです。

pattern:Pattern init:(_ "=" _ a:AssignmentExpression)? => a

問題なのは、テストすると、このpluck実装はバグがあるように見えます。もちろん、これは決してリリースされないブランチで修正されているため、これはクローズとマークされています。

これがリリースされたバージョンで修正されるまで、この問題、 @ futagozaを再度開いてください