pegjs 🚀 - Mendukung penguraian bahasa berbasis lekukan

Sangat berbahaya untuk mengandalkan efek samping yang Anda tambahkan di penangan khusus untuk mengurai tata bahasa berbasis lekukan. Jangan lakukan itu. Pegjs harus menambahkan beberapa kemampuan untuk mendorong dan memunculkan status kondisional untuk membuat lekukan penguraian (dan tata bahasa sensitif konteks lainnya) aman.

Inilah yang saya lakukan untuk saat ini, dan saya sarankan Anda melakukan ini: Praproses file input dan masukkan token indent/outdent Anda sendiri. Saya menggunakan {{{{ dan }}}} masing-masing. Kemudian tata bahasa Anda bebas konteks dan dapat diuraikan secara normal. Ini mungkin mengacaukan nilai baris/kolom Anda, tetapi Anda dapat memperbaikinya di postprocessor.

krisnye pada 11 Feb 2014

👍3

Jika Anda tidak perlu menargetkan javascript, Pegasus , klon pegjs saya untuk C#, memiliki dukungan untuk status push/popping. Berikut artikel wiki tentang cara melakukan apa yang Anda inginkan: https://github.com/otac0n/Pegasus/wiki/Significant-Whitespace-Parsing

Saya ingin mengusulkan agar pegjs menggunakan sintaks saya sebagai titik awal untuk penguraian berbasis negara.

otac0n pada 11 Feb 2014

Kemampuan untuk push dan pop state dengan aman itu bagus. Saya akan menggunakannya jika berbasis Javascript. Tidak layak untuk mengintegrasikan CLR hanya untuk penguraian.

krisnye pada 11 Feb 2014

Itulah yang saya pikirkan. Saya pikir, dalam hal ini, saya mungkin harus mencoba mem-back-port peningkatan saya ke pegjs.

Namun, saya tidak serta-merta ingin melakukannya tanpa berbincang dengan @dmajda.

otac0n pada 12 Feb 2014

👍2

@otac0n Itu bagus. Saya tidak menulis C# . JavaScript jauh lebih baik bagi saya.

jiyinyiyong pada 12 Feb 2014

Bahasa berbasis lekukan itu penting. Saya ingin melihat menyederhanakan parsing mereka setelah 1.0.0.

dmajda pada 21 Apr 2014

Saya pikir masalah ini paling baik diselesaikan dengan mengizinkan keadaan secara umum, seperti yang dilakukan Pegasus dan seperti yang disarankan di #285. Berikut adalah sebuah ide (berikut adalah tata bahasa spasi putih signifikan Pegasus yang diterjemahkan ke pegjs dan dengan ide sintaks saya ditambahkan):

{var indentation = 0}

program
  = s:statements eof { return s }

statements
  = line+

line
  = INDENTATION s:statement { return s }

statement
  = s:simpleStatement eol { return s }
  / "if" _ n:name _? ":" eol INDENT !"bar " s:statements UNDENT {
      return { condition: n, statements: s }
    }
  / "def" _ n:name _? ":" eol INDENT s:statements UNDENT {
      return { name: n, statements: s }
    }

simpleStatement
  = a:name _? "=" _? b:name { return { lValue: a, expression: b } }

name
  = [a-zA-Z] [a-zA-Z0-9]* { return text() }

_ = [ \t]+

eol = _? comment? ("\r\n" / "\n\r" / "\r" / "\n" / eof)

comment = "//" [^\r\n]*

eof = !.

INDENTATION
  = spaces:" "* &{ return spaces.length == indentation }

INDENT
  = #STATE{indentation}{ indentation += 4 }

UNDENT
  = #STATE{indentation}{ indentation -= 4 }

Perhatikan blok #STATE{indentation} dekat bagian bawah (jelas terinspirasi oleh Pegasus). Saya menyebut blok negara bagian itu. Idenya adalah untuk mengizinkan blok status sebelum tindakan. Berikut adalah blok status yang lebih rumit:

#STATE{a, b, arr: {arr.slice()}, obj: {shallowCopy(obj)}, c}

Ini adalah singkatan untuk:

#STATE{a: {a}, b: {b}, arr: {arr.slice()}, obj: {shallowCopy(obj)}, c: {c}}

Dengan kata lain, setelah ekspansi singkatan diterapkan, isi dari blok status adalah daftar identifier ":" "{" code "}" . Menambahkan blok status sebelum tindakan memberi tahu pegjs bahwa tindakan ini akan mengubah pengidentifikasi yang terdaftar, dan jika aturan dilacak mundur, pengidentifikasi tersebut harus disetel ulang ke kode di antara kurung kurawal.

Berikut adalah fungsi yang dikompilasi untuk INDENT dan UNDENT dari tata bahasa di atas, dengan pengaturan ulang variabel indentation ditambahkan:

    function peg$parseINDENT() {
      var s0, s1, t0;

      s0 = peg$currPos;
      t0 = indentation;
      s1 = [];
      if (s1 !== peg$FAILED) {
        peg$reportedPos = s0;
        s1 = peg$c41();
      } else {
        indentation = t0;
      }
      s0 = s1;

      return s0;
    }

    function peg$parseUNDENT() {
      var s0, s1, t0;

      s0 = peg$currPos;
      t0 = indentation;
      s1 = [];
      if (s1 !== peg$FAILED) {
        peg$reportedPos = s0;
        s1 = peg$c42();
      } else {
        indentation = t0;
      }
      s0 = s1;

      return s0;
    }

Dan inilah sedikit bagaimana "blok keadaan rumit" dari atas dapat dikompilasi:

s0 = peg$currPos;
t0 = a;
t1 = b;
t2 = arr.slice();
t3 = shallowCopy(obj);
t4 = c;
// ...
if (s1 !== peg$FAILED) {
  // ...
} else {
  peg$currPos = s0;
  a = t0;
  b = t1;
  arr = t2;
  obj = t3;
  c = t4;
}

Apa pendapat Anda tentang gagasan untuk dapat:

Beri tahu pegjs tentang variabel stateful mana yang akan dimodifikasi oleh suatu tindakan.
Berikan kode yang diperlukan untuk menyimpan variabel tersebut jika perlu diatur ulang. (Termasuk sintaks singkatan untuk kasus sederhana di mana variabel adalah nilai primitif.)

Dan apa pendapat Anda tentang sintaks?

Sunting: Inilah tata bahasa sintaks yang diusulkan (hanya untuk bersenang-senang):

diff --git a/src/parser.pegjs b/src/parser.pegjs
index 08f6c4f..09e079f 100644
--- a/src/parser.pegjs
+++ b/src/parser.pegjs
@@ -116,12 +116,31 @@ ChoiceExpression
     }

 ActionExpression
-  = expression:SequenceExpression code:(__ CodeBlock)? {
+  = expression:SequenceExpression code:((__ StateBlock)? __ CodeBlock)? {
       return code !== null
-        ? { type: "action", expression: expression, code: code[1] }
+        ? {
+            type:       "action",
+            expression: expression,
+            code:       code[2],
+            stateVars:  (code[0] !== null ? code[0][1] : [])
+          }
         : expression;
     }

+StateBlock "state block"
+  = "#STATE{" __ first:StateBlockItem rest:(__ "," __ StateBlockItem)* __ "}" {
+      return buildList(first, rest, 3);
+    }
+
+StateBlockItem
+  = varName:Identifier expression:(__ ":" __ CodeBlock)? {
+      return {
+        type:       "stateVar",
+        name:       varName,
+        expression: expression !== null ? expression[3] : varName
+      };
+    }
+
 SequenceExpression
   = first:LabeledExpression rest:(__ LabeledExpression)* {
       return rest.length > 0

lydell pada 15 Feb 2015

Halo kawan-kawan,
Hanya untuk memperjelas, apakah saya benar bahwa lebih baik tidak menggunakan PEG.js (dengan solusi dari atas masalah ini) dengan bahasa berbasis lekukan sampai masalah ini ditutup?
Terima kasih.

hoho pada 8 Nov 2015

@hoho Saya tidak mengerti maksud Anda .. Tapi saya kemudian menemukan solusi lain untuk mengurai lekukan dengan kombinator parser seperti solusi dan berhasil. Dan saya pikir lekukan asli saya untuk mengurai lekukan dengan PEG.js hilang.

jiyinyiyong pada 9 Nov 2015

Maksud saya ada solusi untuk mengurai lekukan, tetapi komentar mengatakan bahwa solusi ini akan gagal dalam beberapa kasus tertentu.

hoho pada 10 Nov 2015

Biarkan saya mengklarifikasi situasinya: Mengurai bahasa berbasis lekukan di PEG.js dimungkinkan. Ada berbagai solusi yang disebutkan di atas dan saya baru saja membuat yang lain ketika saya mencoba untuk mendapatkan "rasa" untuk ini (ini adalah tata bahasa bahasa sederhana dengan dua pernyataan, salah satunya dapat berisi sub-pernyataan berindentasi - mirip dengan misalnya if dengan Python).

Satu hal yang umum untuk semua solusi adalah mereka perlu melacak status indentasi secara manual (karena PEG.js tidak dapat melakukannya). Ini berarti ada dua batasan:

Anda tidak dapat mengkompilasi tata bahasa dengan caching dengan aman (karena parser dapat menggunakan hasil yang di-cache alih-alih mengeksekusi kode yang memanipulasi keadaan).
Anda tidak dapat melakukan backtrack di seluruh level indentasi (karena saat ini tidak ada cara untuk membuka gulungan status saat melakukan backtracking). Dengan kata lain, Anda tidak dapat mengurai bahasa di mana ada dua konstruksi valid yang dapat disamarkan hanya setelah baris baru dan tingkat lekukan berubah.

Batasan 1 dapat menyebabkan masalah kinerja dalam beberapa kasus, tetapi saya tidak berpikir ada banyak bahasa yang batasan 2 akan menjadi masalah.

Saya setuju dengan keadaan ini hingga 1.0.0 dan saya berencana untuk kembali ke topik ini beberapa saat setelahnya. Tingkat peningkatan pertama dapat menghilangkan batasan 2 menggunakan pelacakan status yang lebih eksplisit (seperti yang disarankan di atas) atau dengan menyediakan kait lacak balik (sehingga seseorang dapat membuka gulungan status dengan benar). Tingkat kedua dapat menghilangkan kebutuhan untuk melacak status indentasi secara manual dengan menyediakan beberapa cara deklaratif untuk melakukannya. Ini bisa membantu dengan batasan 1.

dmajda pada 27 Nov 2015

H, saya menulis tambalan (kecil, retas) untuk PEG.js yang mendukung pelacakan balik yang tepat, seperti yang saya jelaskan di sini: https://github.com/pegjs/pegjs/issues/45

tebbi pada 27 Nov 2015

👍1

maaf atas benturannya

Saya baru saja ingin membuat parser CSON dan YAML untuk bahasa yang saya rancang, dan sambil mencari cara untuk membuat parser berbasis indentasi dengan PEG.js, saya menemukan metode sederhana yang:

1) tidak bergantung pada status push/pop
2) menegaskan level indentasi melalui kode dalam tindakan

Terpikir oleh saya bahwa salah satu dari 2 solusi di atas sebenarnya menambah masalah kinerja ke parser yang dihasilkan. Selain itu menurut saya:

1) mengandalkan status tidak hanya menambahkan sintaks PEG.js yang jelek tetapi juga dapat memengaruhi jenis parser apa yang dapat dihasilkan karena mereka perlu mendukung penyerahan status berbasis tindakan.
2) terkadang menambahkan beberapa kode dalam tindakan menghasilkan aturan yang bergantung pada bahasa, dan untuk beberapa pengembang itu berarti mereka tidak dapat menggunakan plugin untuk menghasilkan parser untuk bahasa lain seperti C atau PHP tanpa menggunakan lebih banyak plugin untuk menangani tindakan pada aturan, yang hanya berarti sistem build yang lebih besar hanya untuk mendukung 1 atau 2 perubahan.

Setelah beberapa saat saya mulai membuat varian saya sendiri dari parser PEG.js dan berpikir: mengapa tidak menggunakan operator awalan increment (“++”) dan decrement (“--”) (__++ ekspresi__ dan __-- ekspresi__ ) untuk menangani hasil ekspresi kecocokan (__ekspresi *__ atau __ekspresi +__).

Berikut ini adalah contoh tata bahasa berdasarkan @dmajda 's Simple bahasa berbasis intentation , ditulis ulang untuk menggunakan baru __ ++ expression__ dan __-- expression__ bukan __ & {predikat} __:

Start
  = Statements

Statements
  = Statement*

Statement
  = Indent* statement:(S / I) { return statement; }

S
  = "S" EOS {
      return "S";
    }

I
  = "I" EOL ++Indent statements:Statements --Indent { return statements; }
  / "I" EOS { return []; }

Indent "indent"
  = "\t"
 / !__ "  "

__ "white space"
 = " \t"
 / " "

EOS
  = EOL
  / EOF

EOL
  = "\n"

EOF
  = !.

Jauh lebih enak dipandang, bukan? Lebih mudah dipahami juga, baik untuk manusia maupun perangkat lunak.

Bagaimana cara kerjanya? sederhana:

1) Indent* memberi tahu parser bahwa kita menginginkan 0 atau lebih dari apa yang dikembalikan Indent
2) ++Indent memberitahu parser untuk meningkatkan jumlah minimum kecocokan yang diperlukan untuk Indent
3) Sekarang setiap kali parser akan mengembalikan kecocokan untuk Indent , parser pertama-tama mengharapkannya menjadi __1 lebih__ cocok dari sebelumnya, jika tidak _peg$SyntaxError_ akan dilempar.
4) --Indent memberitahu parser untuk mengurangi jumlah minimum kecocokan yang diperlukan untuk Indent
5) Sekarang setiap kali parser mencari Indent dan mengembalikan kecocokan yang diharapkan __1 less__ cocok dengan sebelumnya, jika tidak _peg$SyntaxError_ akan dilempar.

Solusi ini adalah cara terbaik untuk menambahkan dukungan untuk 'Significant Whitespace Parsing' tanpa menambahkan sintaks yang jelek ke tata bahasa PEG.js atau memblokir generator pihak ke-3.

Inilah aturan yang diubah untuk menambahkan dukungan untuk parsing ini di _src/parser.pegjs_:

{
  const OPS_TO_PREFIXED_TYPES = {
    "$": "text",
    "&": "simple_and",
    "!": "simple_not",
    "++": "increment_match",
    "--": "decrement_match"
  };
}

PrefixedOperator
  = "$"
  / "&"
  / "!"
  / "++"
  / "--"

SuffixedOperator
  = "?"
  / "*"
  / "+" !"+"

Apakah saya benar untuk berasumsi bahwa untuk mendukungnya sisi kompiler/generator kita harus:

1) tambahkan pass kompiler yang memastikan __++ expression__ atau __-- expression__ hanya digunakan pada __expression *__ atau __expression +__, di mana __expression__ harus bertipe: choice, sequence, atau rule_ref
2) tambahkan pemeriksaan berbasis cache di parser yang dihasilkan untuk __expression *__ atau __expression +__ yang menegaskan kecocokan minimum yang diperlukan terpenuhi sebelum mengembalikan kecocokan
3) secara opsional tambahkan metode pembantu untuk pengurai yang dihasilkan untuk diterapkan yang mengembalikan jumlah kecocokan yang diperlukan untuk aturan yang diberikan, mis. nMatches( name: String ): Number

futagoza pada 15 Mar 2017

@futagoza , ini bersih dan pintar. Saya suka itu. Saya sedang mengerjakan parser yang menangani status, tetapi satu-satunya status yang benar-benar kita butuhkan adalah level indentasi. Saya dapat menggunakan ide ini dan memberi Anda kredit untuk itu. Melacak level indentasi masih secara efektif membutuhkan status push/popping sehingga mungkin masih mencegah beberapa pengoptimalan tetapi semantiknya sangat bagus.

Jika Anda menambahkan operator ke tata bahasa, saya sarankan untuk menambahkan operator awalan @ juga. Tujuannya adalah untuk mengekstrak hasil aturan tunggal dari urutan. Dengan menggunakan itu, tata bahasa sampel menjadi lebih bersih. Tidak ada lagi tindakan sepele { return x }.

Start
  = Statements

Statements
  = Statement*

Statement
  = Indent* @(S / I)

S
  = "S" EOS {
      return "S";
    }

I
  = "I" EOL ++Indent <strong i="8">@Statements</strong> --Indent
  / "I" EOS { return []; }

Indent "indent"
  = "\t"
 / !__ "  "

__ "white space"
 = " \t"
 / " "

EOS
  = EOL
  / EOF

EOL
  = "\n"

EOF
  = !.

@kodyjking apa pendapat Anda tentang ini?

krisnye pada 16 Mar 2017

@futagoza Apakah Anda memiliki garpu/cabang dengan tambalan lekukan diaktifkan dan tata bahasa sampel kecil?