Pegjs: セマンティックアクションの省略形

興味深いアイデアですが、どの引数が関数に渡されているのかが明確でないため、個人的にはそれがより明確な方法になるとは思いません。 また、「カスタム」パラメーターを渡す必要がある場合は、それらを通常の関数呼び出しと組み合わせる必要があるため、単純な場合ほどきれいに見えません。

＃235の誰かが、矢印関数と一緒に構文=>を提案しましたが、これは非常にクリーンで簡潔だと思いました。

  = '(' expr:some_expression ')' => expr
  ;

私は速記構文のために次のいずれかを選択することに傾いています：

• => expr; _（構文のサポートが必要）_
• { => expr } _（現在使用可能ですが、開梱が必要です）_
• { > expr } _（構文のサポートが必要）_

まだ決めていないので、議論の余地があります。

OPが必要とするものについては、Acornまたは@ babel / parserを使用して識別子またはメンバー式をアンラップし、それを呼び出し式に変換するプラグインを実装するのが最善です（省略構文が決定された後または前に）。引数としてラベルを付け、生成されたコードを返します。

=> expr;

私の意見では最高です。

{ => expr }

Javascript構文IMOとの競合。 { }にあるので、完全な矢印関数（ () => ）であることが期待されます。

{ > expr}

PegJSまたはJavascriptの他の構文と少し直交しているため、「これは値を返す、省略形」のIMOをすぐには読み取れません。主に中括弧で囲まれているためです。 {=> expr}と同じ引数で、Javascriptがそこにあることを期待します。

さらに、 {}非JS構文を追加することは、構文ハイライターやリンターなどにとって問題です。私はそれをお勧めしません。

さらに別のオプションを提案する場合は、おそらく>自体（述語ブロック内ではない）です。 これは、ルールを垂直方向に配置するときに、物事を整列させるのに役立ちます。

    = foo:bar qux:(' '+ @qix)+
    > {foo, qux}
    ;

インラインだけでなく

some_rule = foo:bar qux:(' '+ @qix)+ > {foo, qux};

'=>'にセミコロンが必要なのはなぜですか？ たとえば、buildList（）を使用する代わりに、ネストされたコードで値を返したいのですが。

  = "(" _ head:Expression _ tail:("," _ expr:Expression => expr)* ")" {
      return [head, ...tail]
    }

私はこれが魔法のインデックス（下記）を使用するよりもきれいだと思います。 もう1つのオプションは、ネストされたラベルを参照する機能です。 例： ("," _ tail:Expression)* ")"

  = "(" _ head:Expression _ tail:("," _ Expression)* ")" {
      return buildList(head, tail, 2)
    }

parser.pegjsを見ていましたが、434行目あたりにCodeBlockがあることがわかりました。 それを試すために何をする必要がありますか？ ルールコードは単にSourceCharacterを読み取ります。これは単に「。」です。

CodeBlock "code block"
  = "=>" __ <strong i="13">@Code</strong> // this?
  / "{" <strong i="14">@Code</strong> "}"

@mikeaustinええ、その通りですが、このシーケンスをどこで終了するかを知る方法がないため、 =>後にevrythingを消費します

たぶん、「コード」は少し賢く、角かっこと中括弧のバランスを取り、LineTerminatorを処理することができますか？ 完全なJavaScriptについて知る必要はありませんが、それは思ったより難しいかもしれません。

実際、私は考えていましたが、これらの変更はうまくいくかもしれません：

CodeBlock "code block"
  = "=>" _ expession:CallExpression {
       return `return ${ expession };`;
     }
  / "{" <strong i="6">@Code</strong> "}"
  / "{" { error("Unbalanced brace."); }

// Will be based on ECMAScript's CallExpression
CallExpression
  = ...
  / MemberExpression

// Will be based on ECMAScript's MemberExpression
MemberExpression
  = ...
  / ValidIdentifier

// Change `LabelIdentifier` into `ValidIdentifier`

この方法でも、引数として使用するECMAScriptのプライマリ式（数値、ブール値、配列など）などを統合する必要があるため、何を追加するかを慎重に検討する必要があります。

ブラケットとブレースのバランスをとる

これは、適切なJavaScriptパーサーがPEG.jsパーサーに組み込まれるまで修正されませんが、他の言語（C、PHP、TypeScript）でパーサーを生成するプラグインプロジェクトがいくつかあるため、正直なところ、これについては少し躊躇しています。など）、そして私はまた、いつかパーサーを生成したいと思っているコンピューター言語に取り組んでいます。

_PEG.js v0.12_と一緒に、OpenPEGに取り組んでいます。これは、JavaScriptやパーサーの生成を伴わない基本的にPEG.jsの簡略版であるNPMパッケージを提供しますが、JavaScriptベースのプロジェクトがPEG.jsはそれをバックエンドとして使用できます。 _v0.12_が出たら、カスタムパーサーを生成するプラグインプロジェクトにOpenPEGが通知されるようにし、v1の前に完全なECMAScript2015パーサーをPEG.js文法パーサーに実装します。

FWIW、私はこれにテンプレートリテラルを使い始めました。 また、テキストエディタによるJSの構文の強調表示にも役立ちます...

exports = module.exports = functionBodies`${grammarScript}
...
objectText =
    head:word
    rest:(_txt_ word)*
    ${f=>{
        return new Txt(rest.reduce((a,b)=>([...a,...b]),[head]))
        }}
word = ch:(wordCharacter/escapedCharacter)+ ${chJoin}
...
`
function functionBodies(glue, ...fns){
    return glue.map( (str,i) => str + (fns[i]||'').toString().replace(/^[^{]*/,'').replace(/[^}]*$/, '') ).join('')
    }

function chJoin(ch){return ch.join('')}

提案されたパイプ演算子（https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Pipeline_operator）を使用するのはどうですか？ 基本的に、データをパイプするように求めているのですか？

{
  function extract(value) {
    return value;
  }
  function concat(head, tail) {
    return head ? [head].concat(tail) : [];
  }
  function toAddExpr(head, tail) {
    return { type: 'addExpr', expressions: concat(head, tail) };
  }
}

List
  = '(' _ head:Item? tail:( _ ',' _ value:Item |> extract )* _ ')' |> concat

// Another kind of list
Add
  = '(' _ head:Multiply? tail:( _ '+' _ value:Multiply |> extract  )* _ ')' |> toAddExpr

これは起こらないはずです。 短い構文があってはなりません。

矢印を横向きにシムしようとするのではなく、通常どおりに矢印を解析する場合は、これは必要ありません。

これは素晴らしいアイデアですが、JavaScriptと比較して文法のあいまいさが大きくなります。 JSを解析し、 with大失敗が何であったかを覚えている人なら誰でも、これが基本的にパーサーを殺害することを知っています。

派手な新しいものを作成しようとするのではなく、Javascriptをサポートする必要があります。 矢印機能はES6より古く、ES6は2015年のものです。これは6年前に解決されました。 ここでは発明は起こらないはずです。

パイプ演算子にはひどい欠陥があり、おそらく実際にはJavascriptに組み込まれず、元々の言語（F＃）とそれを普及させた言語（Elixir）の両方がそれから遠ざかっています。 その上、これはいかなる意味でも配管ではありません。

PEGが非常に成功した理由は、PEGが最小限であり、言語に近いままであり、高速、小型、および予測可能であるためです。

矢印機能はES6より古く、ES6は2015年のものです。これは6年前に解決されました。 ここでは発明は起こらないはずです。

ええと。 それは私にとってのニュースです。 拡大する気ですか？

PEGが非常に成功した理由は、PEGが最小限であり、言語に近いままであり、高速、小型、および予測可能であるためです。

PEG（このライブラリではなく概念として）が成功する理由は、複雑な文法（再帰など）を単純な方法で表現できるためです。 Packratはこのライブラリで発明されたものではありません。 構文ではありません。 それはアルゴリズムです。

矢印機能はES6より古く、ES6は2015年のものです。これは6年前に解決されました。 ここでは発明は起こらないはずです。

ええと。 それは私にとってのニュースです。 拡大する気ですか？

私はあなたが何を求めているのか本当にわかりません。

矢印関数はES6より古いです。 これはES6で2番目に大きな戦いであり、ES4を狂わせたもの、そしてES5 +を狂わせたものです。 その時点で、90年代半ばから、誰もがそれらを求めていました。なぜなら、それらは実際にはE4Xにすでに存在していたためであり、GoogleとAppleがMicrosoftがこれまでに何かを発明したことについてHixieに適合したために取り上げられました。

あなたは今E4XをReactとして知っており、Facebookがそれを発明したと思います。 Facebookは彼らがHyperscriptをはぎ取ったと考えています。 Hyperscriptの男は、彼が古いIEから有用なものを再実装しただけであることを明確にしています。

テンプレート文字列と同じように、ES6から完全に除外される予定でしたが、Coffeescriptが登場し、JSコミュニティに両方を提供し、その後JSコミュニティはECMAの人々が怒鳴るまで怒鳴りました。 たった18ヶ月しかかかりませんでした

矢印関数は、ここで発生する必要があるすべてのことを実行します。 あなたは2018年にこのスレッドで彼らを育てた人でさえあるようです。それはあなたの意見の不一致を非常に驚くべきものにします。 私はあなたをバックアップしようとしていました。

私にとってもっと重要なことは、それが矢印関数で行われた場合、何も追加されていないということです。

ペグとJSの違いはごくわずかです。 ES6を実行するだけでこれをサポートするということは、リストが変更されないことを意味します。

それは非常に価値があります。

PEG（このライブラリではなく概念として）が成功する理由は、複雑な文法（再帰など）を単純な方法で表現できるためです。

同意しません。 多くのパーサーはこれをはるかに上手くこなし、それらについて知っている人々（Earleyのような）でさえ、少しでも人気がありません。

従来の説明はエラーメッセージの品質と速度の組み合わせですが、多くのパーサーはより高速なエラーメッセージを持っており（これもEarleyのように）、人々の間でも少しでも人気がないため、私もそれに同意しません。それらについて知っている人

また、PEGには3つの深刻な複雑さの上限があることに注意してください。

1つは、ペグ文法を使用する場合は、ローカルマシンのキャッシュと評価スループットを圧倒しない組み合わせ式を使用する必要があります（例＃623）

2つ目は、BNFの解析など、多くの一般的な作業がペグで残酷に困難な場合が多いことです（例＃489）

3つ目は、他のすべてのJS PEGライブラリー、さらにははるかに強力なライブラリーが失敗したことです。 私は何度も切り替えようとしましたが、戻ってきました。 特に、 c 、 ruby 、およびpythonを追加でターゲットにできるため、何度もcanopyに切り替えようとしました。 javascript

確かに、私が話すことができるのは、それを使用している私が知っている20人ほどの人々だけです。 そして、数日前に尋ねたので、何年にもわたって公開された変更がなかった後、新しい非保守者がソフトウェアを破棄し、彼がゼロから作成したものと交換していることに気付いたとき、私はできます

しかし、彼らの一人一人が私に、ネイティブの概念的なオーバーヘッドがあまりないパーサーが必要であるか、動作が信頼できる高速で小さなものが必要であると言いました

リリースされていない0.11は、ノードとクロムで意味のある動作が異なり、ノードはクロムでできています。 それに対していくつかのプロパティテストを書いてみてください。 正直なところ、恐ろしいことです。

。

Packratはこのライブラリで発明されたものではありません。 構文ではありません。 それはアルゴリズムです。

友達のPackratについては何も言わなかった。 何を修正しようとしているのかわかりません。

ただし、ソートがアルゴリズムではないのと同じ理由で、Packratの解析はアルゴリズムではありません。 Packratの解析はタスクであり、それを実行する方法はたくさんあります。

実際、ほとんどのIntro Haskellの本では、3つまたは4つの異なるpackratパーサーを実行できます。これは、haskellのモナドへのアプローチのパフォーマンスの問題に実際に夢中になるための優れた方法であり、書き込みへのアプローチをどのように変更するかを示したいためです。 packrats（つまり、アルゴリズムの変更）は、より良い結果をもたらします。

。

親指を下に向けて考え直してください。 この図書館は3年前に亡くなりましたが、今すぐ復活させたいと思います。

ライブラリが死んでいる理由の一部は、人々が2年間開発に置かれているes()モジュール関数を追加するなどの単純なメンテナンスを実行するのではなく、機能をグリーンフィールドで発明しようとし続けることです。

行を切り取り、手書きのJavaScriptをホッチキスで留めて、PEGパーサーを手動で変更する必要があります。

星空の目が少し閉じて、実用的な脂っこい肘が始まるはずです。 PEGは、使用が減少しているのを私が今まで見た中で唯一の主要なNPMライブラリです。 私が合理的な代替品を知らないことを考えると、それは私にとって奇妙で混乱を招きます。

今すぐ投稿したいバグ修正がありますが、投稿できません。

1. 0.10は、dmajdaが去ってから公開されていませんが、
2. 0.11は3歳で、公開されたことがなく、1か月前に公開されることはないと発表されました。
3. 代わりの0.12はペグではありませんが、他の人が別のプログラミング言語で最初から書いたものであり、誰もそれを見ることができません。

私はそれが失礼であることを知っています、しかし私たちはこの図書館が殺されていることに直面する必要があります

このライブラリが再び更新を確認する場合は、通常の開発プロセスを受け入れる必要があることに直面する時が来ました。 2020年です。2017年以来何も見ていません。

いいえ、devブランチはカウントされません。 また、 0.11は十分な品質ではなく、 10からやり直す方が、 11修正するよりもはるかに少ない作業であるため、新しいメンテナは多くの問題を再開する必要11