Pegjs: Kemampuan untuk mengabaikan produksi tertentu

Sepakat. Apakah ada cara bersih untuk melakukan ini saat ini?

@benekastah : Tidak ada cara yang bersih sampai sekarang.

Ini akan sulit dilakukan tanpa mengubah cara kerja PEG.js. Solusi yang mungkin termasuk:

1. Izinkan untuk menambahkan lexer sebelum parser yang dihasilkan.
2. Cantumkan informasi tentang aturan yang sudah tertanam di suatu tempat dalam tata bahasa. Itu mungkin juga berarti membedakan antara tingkat tata bahasa leksikal dan sintaksis — sesuatu yang ingin saya hindari.

Saya tidak akan mengerjakan ini sekarang tetapi ini adalah sesuatu yang perlu dipikirkan dalam fitur ini.

Saya akan membutuhkan fitur ini untuk.

Mungkin Anda bisa memperkenalkan Token "lewati". Jadi jika aturan mengembalikan token itu, itu akan diabaikan dan tidak mendapatkan node di AST (alias entri dalam array).

Saya mencari cara untuk melakukan ini juga.

Saya memiliki file tata bahasa yang besar (ini mem-parsing format ASN.1 untuk file SNMP MIB). Saya tidak menulisnya, tapi saya mengubahnya dari bentuk aslinya untuk membuat parser di PEG.js. (Ini bagus. Faktanya, ini sangat licin sehingga saya membutuhkan waktu kurang dari 15 menit untuk mengubahnya sehingga PEG.js akan menerimanya.)

Sayangnya, tata bahasa ditulis dengan kemampuan untuk mengabaikan spasi dan komentar saat bertemu dengannya. Akibatnya, tidak ada file MIB nyata yang dapat ditangani, karena parser berhenti pada kemunculan spasi putih pertama.

Saya tidak ingin harus mencari tahu tata bahasa sehingga saya bisa memasukkan semua spasi yang tepat di semua aturan (ada sekitar 126 produksi ...) Apakah ada cara lain untuk melakukan ini?

NB: Jika saya harus mengubah tata bahasa dengan tangan, saya meminta bantuan untuk beberapa pertanyaan di tiket di daftar Grup Google. http://groups.google.com/group/pegjs/browse_thread/thread/568b629f093983b7

Terimakasih banyak!

Terima kasih kepada orang-orang di Google Grup. Saya pikir saya mendapat informasi yang cukup untuk memungkinkan saya melakukan apa yang saya inginkan.

Tapi saya sangat menantikan kemampuan di PEG.js untuk menandai spasi/komentar sebagai sesuatu yang harus diabaikan sepenuhnya sehingga saya tidak perlu waktu beberapa jam untuk mengubah tata bahasa yang bersih... Terima kasih!

Kaya

Saya setuju dengan pernyataan bahwa pegjs membutuhkan kemampuan untuk melewati token. Saya mungkin melihatnya, karena jika Anda ingin menulis tata bahasa yang serius, Anda akan menjadi gila ketika meletakkan ws di antara setiap token.

Karena parser yang dihasilkan bersifat modular. Sebagai solusinya, buat lexer sederhana dan gunakan outputnya sebagai input untuk yang asli, misalnya:

elideWS.pegjs:

s = input:(karakter spasi putih / karakter teks)*
{
var hasil = "";

for(var i = 0;i < input.length;i++) hasil += input[i];
kembali hasil;
}

whitespaceCharacter = [ nt] { kembali ""; }
textCharacter = c:[^ nt] { kembali c; }

tapi itu menyebabkan masalah ketika spasi putih adalah pembatas -- seperti untuk pengidentifikasi

Sering bertemu dengan masalah ini.
Tetapi tidak mudah untuk menulis lexer yang baik (Anda bisa berakhir dengan menduplikasi sebagian besar tata bahasa awal untuk mendapatkan lexer yang koheren).

Apa yang saya pikirkan adalah untuk dapat mendefinisikan aturan lewati yang dapat digunakan sebagai alternatif setiap kali tidak ada kecocokan. Ini memperkenalkan perlunya kelas yang tidak melanggar. Contoh dengan arithmetics.pegjs menggunakan Floats

  = Term (("+" / "-") Term)*

Term
  = Factor (("*" / "/") Factor)*

Factor
  = "(" Expression ")"
  / Float

Float "float"
  = "-"? # [0-9]+ # ("." # [0-9]+) // # means that skip rules cannot match

// skip rule marked by "!="
// skip rules cannot match the empty string
_ "whitespace"
  != [ \t\n\r]+

Masih mencerna ini. Ada tanggapan? Mungkin itu ide yang sangat bodoh.

Jadi perbedaannya adalah Anda ingin membedakan kapan mesin keseluruhannya
beroperasi dalam mode lexer (spasi putih signifikan) dan ketika tidak (spasi putih adalah
diabaikan).

Apakah ada kasus ketika Anda ingin tidak mengabaikan spasi saat dalam mode lexer?
sebagai pilihan? Atau sebaliknya, ketika tidak di dalam regex? Saya pikir tidak.

Akankah yang berikut ini setara?

Mengambang
"-?[0-9]+("." [0-9]+)”

atau perpanjang pasak untuk memproses regex tipikal secara langsung dan di luar
string yang dikutip (yang mencakup regex) spasi diabaikan.

Pada 19 April 2014, pukul 15.22, Andrei Neculau [email protected] menulis:

Sering bertemu dengan masalah ini.
Tetapi tidak mudah untuk menulis lexer yang baik (Anda bisa berakhir dengan menduplikasi sebagian besar tata bahasa awal untuk mendapatkan lexer yang koheren).

Apa yang saya pikirkan adalah untuk dapat mendefinisikan aturan lewati yang dapat digunakan sebagai alternatif setiap kali tidak ada kecocokan. Ini memperkenalkan perlunya kelas yang tidak melanggar. Contoh dengan arithmetics.pegjs menggunakan Floats

Ekspresi
= Suku (("+" / "-") Suku)*

Ketentuan
= Faktor (("_" / "/") Faktor)_

Faktor
= "(" Ekspresi ")"
/ Mengambang

Mengapung "mengambang"
= "-"? # [0-9]+ # ("." # [0-9]+) // # berarti aturan lewati tidak cocok

// lewati aturan yang ditandai dengan "!="
// lewati aturan tidak bisa cocok dengan string kosong
_ "spasi putih"
!= [ tnr]+
Masih mencerna ini. Ada tanggapan? Mungkin itu ide yang sangat bodoh.

—
Balas email ini secara langsung atau lihat di GitHub.

@waTeim Sebenarnya tidak.

Secara tradisional proses parsing dibagi menjadi lexing dan parsing. Selama lexing setiap karakter penting, termasuk spasi. Tapi ini kemudian dimasukkan ke dalam token "buang". Pengurai, saat maju ke token berikutnya, kemudian akan membuang semua token yang dibuang. Bagian yang penting adalah Anda dapat membuang apa pun, bukan hanya spasi putih. Perilaku ini persis seperti yang dijelaskan oleh

Ide dasar bagaimana menerapkan ini adalah dengan perlu memeriksa tambahan terhadap semua aturan pembuangan saat bertransisi dari satu keadaan ke keadaan berikutnya.

Pada 23 April 2014, pukul 14.54, Sean Farrell [email protected] menulis:

@waTeim Sebenarnya tidak.

Jadi kami setuju. Pendekatan tradisional sudah cukup. Tidak perlu memiliki
bagian pengurai yang ketat mengenali keberadaan token yang dibuang dan ada
tidak ada alasan untuk membuat bagian lexer berperilaku kondisional (dalam cara yang sensitif konteks)
wrt mengenali token.

Oleh karena itu tidak perlu memiliki elemen lem (misalnya '#') dalam bahasa
karena itu cukup

1) token dapat dibuat hanya dari regex dan tidak peka konteks.
2) token dapat ditandai untuk dibuang tanpa kecuali.

Secara tradisional proses parsing dibagi menjadi lexing dan parsing. Selama lexing setiap karakter penting, termasuk spasi. Tapi ini kemudian dimasukkan ke dalam token "buang". Pengurai, saat maju ke token berikutnya, kemudian akan membuang semua token yang dibuang. Bagian yang penting adalah Anda dapat membuang apa pun, bukan hanya spasi putih. Perilaku ini persis seperti yang dijelaskan oleh

Ide dasar bagaimana menerapkan ini adalah dengan perlu memeriksa tambahan terhadap semua aturan pembuangan saat bertransisi dari satu keadaan ke keadaan berikutnya.

—
Balas email ini secara langsung atau lihat di GitHub.

Oke kalau begitu aku salah paham denganmu. Mungkin ada kasus untuk status lexer, tetapi itu adalah persyaratan yang sama sekali berbeda dan IMHO di luar cakupan peg.js.

@waTeim @rioki Lupakan sedikit tentang saran saya.

Tangan, ambil aturan ini . Jika Anda ingin menyederhanakan tata bahasa aturan dengan menghilangkan *WS , lalu bagaimana Anda akan menginstruksikan PEGjs untuk tidak mengizinkan *WS antara field_name dan : ?

@andreineculau Karena tata bahasa Anda sensitif terhadap spasi, ini tidak berlaku. Token yang dibuang akan menjadi bagian dari tata bahasa, tepatnya bagian lexing. Saya tidak tahu apa masalah besarnya di sini, ini sudah cukup terpecahkan di tahun 70-an. Setiap bahasa memiliki token yang dapat dilewati sendiri dan di mana mereka dapat diterapkan. Spasi putih dan komentar adalah bagian dari definisi bahasa dan dengan demikian bagian dari tata bahasa. Ternyata dengan sebagian besar bahasa, token yang dapat dilewati mungkin berada di antara masing-masing dan setiap token lainnya dan menggunakan aturan buang membuatnya JAUH lebih sederhana daripada menulis expr = WS lit WS op WS expr WS ";" untuk setiap aturan. Bayangkan tata bahasa seperti yang untuk C dengan penanganan whitepsace?

Saya mengerti bahwa mengubah aturan buangan menjadi pegjs tidak mudah, tetapi itu tidak berarti bahwa itu bukan tujuan yang terpuji.

Oh man, bagian respons gratis! Banyak yang ingin saya ceritakan, maaf kepanjangan.

1) Untuk orang-orang TL;DR, jika saya bisa menambahkan elemen pasak, saya ingin, saya akan menulisnya seperti ini

header_field
= field_name ":" field_value

spasi putih(ABAIKAN)
= [t ]+

Tambahan yang akan saya buat adalah bagian opsi yang mungkin disertakan dalam produksi apa pun

Bahasa http-bis tidak akan dibatasi oleh penulisan ulang ini (lihat lampiran a).

2) Masalah saya dengan # yang diusulkan

Rasanya seperti Anda bertukar mengharuskan pengguna untuk mengisi definisi parser dengan banyak
membuang non terminal (biasanya spasi/pembatas) dengan mengharuskan pengguna untuk mengisi
definisi parser dengan sekelompok "karakter di sini tidak dibuang" meta-karakter
tidak perlu. Diakui akan ada lebih sedikit kejadian ini. Ini adalah kasus yang jarang terjadi ketika
orang benar-benar mengonsumsi pembatas dan melakukan sesuatu dengannya, dan seperti yang saya komentari

lampiran a, HTTP-bis bukan salah satu dari kejadian itu, hanya didokumentasikan dengan buruk.

3) Status parser yang ditentukan pengguna

Tapi saya bisa melihat bagaimana akan lebih mudah pada definisi parser untuk hanya memotong dan menempelkan
spesifikasi bahasa dari definisi, jadi jika Anda harus memiliki sesuatu seperti ini, maka
ini bisa dilakukan dengan keadaan leksikal seperti yang disinggung sebelumnya oleh Sean. Saya pikir saya akan melakukannya
dengan cara berikut.

produksi1(status==1)
= barang

produksi2(status==2)
= barang

produksi3
= barang {status = 1}

produksi4
= barang {status = 2}

Dengan kata lain, seperti lex/yacc memungkinkan produksi hanya tersedia

jika sistem berada dalam status tertentu, dan memungkinkan pengguna untuk menetapkan nilai status tersebut.

4) Lebih banyak pilihan

Atau Anda bisa membuatnya lebih mudah bagi pengguna dan lebih jelas bagi pembaca dengan yang lain
pilihan

produksi (TIDAK DIABAIKAN)
= barang

Yang akan memungkinkan parser untuk menimpa tindakan default membuang token yang ditandai
sebagai buangan tetapi hanya untuk satu produksi itu. Ini benar-benar sama dengan 3, hanya lebih mudah
Baca. Ini kurang fleksibel daripada # proposal karena salah satu produksi diabaikan

atau tidak abaikan, tetapi saya tidak berpikir bahwa fleksibilitas ekstra diperlukan.

5) Menambahkan parameter ke getNextToken() memungkinkan sensitivitas konteks

Saya pikir semua ini bermuara pada (saya membuat beberapa asumsi di sini) saat ini,
bagian parser memanggil getNextToken(input), dan yang perlu terjadi adalah menambahkan a

parameter untuk itu getNextToken(input,options).

Lampiran a) Spesifikasi HTTP-bis itu

Ok saya sudah membaca beberapa tetapi belum membaca semua ini

Protokol Transfer Hypertext (HTTP/1.1): Sintaks dan Perutean Pesan
draft-ietf-httpbis-p1-messaging-26

Saya tidak suka cara mereka mendefinisikan tata bahasa mereka. Saya tidak menyarankan mengubah inputnya
menerima, tetapi saya tidak akan mendefinisikannya seperti yang mereka lakukan. Secara khusus, saya tidak suka mengapa mereka memiliki
mendefinisikan OWS dan RWS dan BWS yang semuanya sama persis dengan string karakter yang sama
tetapi dalam konteks yang berbeda. Mereka telah mendefinisikan

OWS ::== (SP | HTAB)*
RWS ::== (SP | HTAB)+
BWS ::== OWS

yang hanya pengulangan tab dan spasi

Tanpa alasan yang bagus. Mereka telah membuat bahasa lebih sulit untuk diuraikan — memerlukan penganalisis leksikal
untuk melacak konteksnya — dan mereka tidak perlu melakukan itu.

Mereka telah mendefinisikan OWS sebagai "spasi putih opsional" BWS sebagai "spasi buruk" atau opsional
spasi putih tetapi dalam konteks "buruk" — jika tidak diperlukan — dan RWS membutuhkan spasi putih jika diperlukan
diperlukan untuk membatasi token. Tidak ada spasi putih ini yang digunakan kecuali mungkin ada parser
peringatan jika cocok dengan BWS ("terdeteksi spasi putih yang tidak perlu" atau semacamnya) itu saja
pembatas lakukan pula.

Dalam spesifikasi mereka, satu-satunya tempat RWS digunakan adalah di sini

Via = 1#( RWS protokol diterima diterima-oleh [ komentar RWS ] )

 received-protocol = [ protocol-name "/" ] protocol-version
                     ; see Section 6.7
 received-by       = ( uri-host [ ":" port ] ) / pseudonym
 pseudonym         = token

tapi 'protocol-version' adalah angka dan mungkin huruf, sedangkan 'received-by' adalah angka dan huruf. Dengan kata lain,
penganalisis leksikal tidak akan mengenali 2 bagian ini dengan benar kecuali jika dipisahkan oleh spasi
dan itu akan menjadi kesalahan sintaks dengan atau tanpa RWS diidentifikasi secara eksplisit jika tidak ada setidaknya 1
karakter spasi putih. Jadi hapus saja RWS dari produksi dan perlakukan spasi putih
di mana-mana sebagai pembatas dan tidak mengubah bahasa, hanya bagaimana itu didokumentasikan.

Pada 24 April 2014, pukul 13.23, Andrei Neculau [email protected] menulis:

@waTeim @rioki Lupakan sedikit tentang saran saya.

Tangan di, mengambil aturan ini. Jika Anda ingin menyederhanakan tata bahasa aturan dengan menghapus OWS, lalu bagaimana Anda akan menginstruksikan PEGjs untuk tidak mengizinkan OWS antara field_name dan :?

—
Balas email ini secara langsung atau lihat di GitHub.

@waTeim Saya pikir Anda berlebihan dengan ini. Saya telah menulis beberapa parser dan saya pikir lexer menyatakan di mana tidak pernah benar-benar berguna seperti itu. Dalam kebanyakan kasus saya melihat mereka adalah di mana lexer mengkonsumsi komentar blok dan "lebih sederhana" untuk menempatkan lexer ke dalam "mode komentar blok" dan menulis pola yang lebih sederhana daripada pola über untuk mengkonsumsi komentar (dan menghitung baris).

Saya belum pernah melihat penggunaan yang tepat dari status lexer yang berasal dari parser. Masalah mendasar di sini adalah bahwa dengan sekali melihat ke depan, ketika parser melihat token untuk beralih status, lexer telah secara keliru me-lex token berikutnya. Apa yang Anda usulkan hampir tidak mungkin diterapkan tanpa pelacakan balik dan itu tidak pernah menjadi fitur yang baik dalam pengurai.

Saat menulis tata bahasa, Anda pada dasarnya menentukan produksi mana yang dianggap diurai dan apa yang bisa disedot. Dalam contoh @andreineculau ada dua opsi, apakah Anda menangani spasi putih di parser atau Anda menentukan bagian ":" tambahan dari token. ( [a-zA-Z0-9!#$%&'+-.^_|~]+ ":" ).

Saya mungkin menyarankan untuk mengubah masalah menjadi menentukan daftar putih — bagian mana yang ingin saya tangkap dan ubah — alih-alih daftar hitam. Meskipun spasi putih adalah salah satu masalah dengan sistem penangkapan saat ini, aturan bersarang adalah masalah lain. Seperti yang saya tulis di Edisi #66, sistem LPeg untuk menentukan apa yang ingin Anda tangkap secara langsung, melalui transformasi atau tangkapan string, tampaknya lebih berguna bagi saya daripada menentukan beberapa produksi untuk dilewati dan masih berurusan dengan sarang dari setiap produksi lainnya.

Lihat komentar saya di Edisi #66 untuk contoh sederhana LPeg versus PEG.js sehubungan dengan tangkapan. Meskipun namanya agak samar, lihat bagian Menangkap pada dokumentasi LPeg untuk mengetahui berbagai cara Anda dapat menangkap atau mengubah produksi tertentu (atau bagiannya).

Halo, saya telah membuat cuplikan untuk mengabaikan beberapa kasus umum: null , undefined dan string dengan simbol spasi saja.
Itu dapat diperlukan di kepala file tata bahasa, seperti:

{
  var strip = require('./strip-ast');
}

Dua cara untuk memperbaikinya:

• Filter yang dapat disesuaikan untuk istilah — untuk mengabaikan istilah tertentu yang memerlukan tata bahasa tertentu.
• Lewati array kosong bersarang — ini dapat dilakukan pada tahap kedua setelah strip , ini akan menghapus «piramida» dari array kosong bersarang.
  Jika ada yang tertarik, kita bisa mengupgradenya menjadi satu paket.

@richb-hanover Di mana upaya parser definisi ASN.1 Anda mendarat?

@atesgoral - saya ditebus. Saya tidak memerlukan "parser nyata" - saya hanya perlu mengisolasi elemen bernama tertentu dalam file target.

Jadi saya melakukan apa yang akan dilakukan pria lemah mana pun - menggunakan ekspresi reguler. (Dan kemudian saya punya dua masalah :-)

Tapi itu berhasil, jadi saya bisa melanjutkan ke tantangan berikutnya. Semoga berhasil dalam proyek Anda!

Setelah melihat chevrotain dan opsi lewati , sesuatu seperti ini sangat diinginkan.

Terlalu sering kita mendapati diri kita menulis sesuatu seperti ini:

Pattern = head:PatternPart tail:( WS "," WS PatternPart )*
{
  return {
    type: 'pattern',
    elements: buildList( head, tail, 3 )
  };
}

Akan lebih keren jika kita bisa menulis ini sebagai gantinya:

WS "whitespace" = [ \t\n\r] { return '@<strong i="11">@skipped</strong>' }

IgnoredComma = "," { return '@<strong i="12">@skipped</strong>' }

Pattern = head:PatternPart tail:( WS IgnoredComma WS PatternPart )*
{
  return {
    type: 'pattern',
    elements: [head].concat(tail)
  };
}

@richb-hanover, dan siapa pun yang datang ke sini untuk mencari kebutuhan serupa, saya akhirnya menulis parser saya sendiri juga: https://www.npmjs.com/package/asn1exp dan https://www.npmjs. com/package/asn1-tree

Lewati akan relatif mudah diterapkan menggunakan es6 symbol , atau mungkin lebih tahan lama dengan memberikan parser predikat pada waktu parse (saya lebih suka opsi yang terakhir)

Barusan juga nemu ini.
Tidak tahu apa-apa tentang jeroan PEG.js, biarkan aku membuang tulang di sana ...

Saat kita menulis aturan, di akhir kita bisa menambahkan blok kembali.
Di blok itu, kita bisa memanggil hal-hal seperti text() dan location() . Ini adalah fungsi internal.

Di suatu tempat dalam kode, nilai yang dikembalikan dari blok itu masuk ke aliran keluaran.

Jadi apa yang perlu diubah di PEG.js jika saya ingin melewatkan nilai yang dikembalikan oleh aturan jika nilai itu adalah kembalinya pemanggilan fungsi lokal skip ?

misalnya comment = "//" space ([^\n])* newline { return skip() }

Seperti disebutkan di atas, skip() dapat mengembalikan Simbol, yang kemudian diperiksa oleh kode di suatu tempat dan dihapus.
Sesuatu seperti apa yang dikatakan lzhaki, tetapi internal ke perpustakaan

Saya tidak mengerti pertanyaan Anda. Apakah Anda mencari cara untuk menggagalkan aturan dalam beberapa keadaan? Gunakan &{...} atau !{...} . Kalau tidak, jangan gunakan nilai yang dikembalikan dari aturan comment :

seq = comment r:another_rule { return r; };
choice = (comment / another_rule) { <you need to decide what to return instead of "comment" result> };

Jika itu membantu siapa pun, saya mengabaikan spasi putih dengan meminta aturan tingkat atas saya memfilter larik hasil.

Contoh:

    = prog:expression+ {return prog.filter(a => a)}

expression
    = float
    / number
    / whitespace

float
    = digits:(number"."number) {return parseFloat(digits.join(""),10)}

number 
    = digits:digit+ {return parseInt(digits.join(""),10)}

digit 
    = [0-9]

whitespace
    = [ \t\r\n] {return undefined}

Ini akan dengan senang hati mem-parsing input sambil menjaga spasi dari array hasil.
Ini juga akan berfungsi untuk hal-hal seperti komentar, hanya membuat aturan kembali tidak ditentukan dan aturan tingkat atas akan memfilternya

Itu hanya berfungsi untuk produksi tingkat atas. Anda harus memfilter secara manual setiap orang tua yang dapat berisi anak yang dapat difilter.

@StoneCypher Benar, itu memang membutuhkan beberapa pekerjaan tingkat atas, tetapi itu berhasil untuk saya, dan saya pikir selama gammar tidak terlalu rumit, seseorang harus dapat lolos dengan memiliki filter tingkat atas.

Selain itu, yang dapat saya pikirkan adalah memiliki fungsi tingkat atas yang menyaring spasi putih dari input dan melewati setiap kecocokan melaluinya. Lebih lambat pasti, dan membutuhkan lebih banyak panggilan, tetapi mudah jika Anda (seperti saya) meneruskan semuanya ke generator token. Anda dapat memanggil fungsi filter dari mana Anda menghasilkan token, dan hanya perlu khawatir tentang menghasilkan token Anda dan spasi putih kurang lebih difilter secara otomatis

Salah satu hal yang saya suka tentang HEAD pegjs saat ini adalah dukungannya (tidak berdokumen) untuk memilih bidang tanpa harus membuat label dan melakukan pernyataan pengembalian. Ini terlihat seperti ini:

foo = <strong i="6">@bar</strong> _ <strong i="7">@baz</strong>
bar = $"bar"i
baz = $"baz"i
_ = " "*

parse('barbaz') // returns [ 'bar', 'baz' ]

Saya merasa ini memberikan sintaks yang bagus, bersih, dan eksplisit untuk kasus penggunaan ini ditambah banyak lainnya.