ชื่อตัวแยกวิเคราะห์ประเภทนี้หรือสาเหตุที่ไม่มีอยู่

ตัวแยกวิเคราะห์แบบเดิมใช้อินพุตทั้งหมดและสร้างต้นแยกวิเคราะห์เดี่ยว ฉันกำลังมองหาอุปกรณ์ที่ใช้กระแสข้อมูลอย่างต่อเนื่องและสร้างฟอเรสต์แยกวิเคราะห์ [ แก้ไข: ดูการสนทนาในความคิดเห็นเกี่ยวกับสาเหตุที่การใช้คำนี้แบบไม่เป็นทางการ ] ไส้ของฉันบอกว่าฉันไม่สามารถเป็นคนแรกที่ต้องการ (หรือคิดว่าฉันต้องการ) ตัวแยกวิเคราะห์ แต่ฉันได้ค้นหาและใช้เวลาหลายเดือนเพื่อหาประโยชน์

ฉันรู้ว่าฉันอาจติดปัญหา XY จุดประสงค์สูงสุดของฉันคือการแยกวิเคราะห์ข้อความโดยไม่สนใจส่วนใหญ่และสร้างกระแสการแยกวิเคราะห์ต้นไม้จากส่วนที่รับรู้

ดังนั้นคำถามของฉันคือมีเงื่อนไข: ถ้ามีคลาส parsers ที่มีคุณสมบัติเหล่านี้อยู่มันเรียกว่าอะไร? และถ้าไม่ทำไมไม่ ทางเลือกคืออะไร? บางทีฉันหายไปด้วยวิธีที่ฉันสามารถทำให้ parsers ทั่วไปทำในสิ่งที่ฉันต้องการ

ตัวแยกวิเคราะห์ที่ส่งกลับ (บางส่วน) ผลก่อนที่จะมีการป้อนข้อมูลทั้งหมดได้รับการบริโภคที่เรียกว่าแยกวิเคราะห์ที่เพิ่มขึ้น การแยกวิเคราะห์ที่เพิ่มขึ้นอาจเป็นเรื่องยากหากมีความคลุมเครือในท้องถิ่นในไวยากรณ์ที่ตัดสินใจได้ในภายหลังในอินพุตเท่านั้น ปัญหาอีกประการหนึ่งคือการแกล้งทำเป็นส่วนต่าง ๆ ของต้นแจงที่ยังไม่ถึง

เครื่องมือแยกวิเคราะห์ที่ส่งคืนป่าของต้นไม้แยกวิเคราะห์ที่เป็นไปได้ทั้งหมดนั่นคือส่งคืนต้นไม้แยกวิเคราะห์สำหรับไวยากรณ์ที่ไม่ชัดเจนที่เป็นไปได้ในแต่ละครั้งเรียกว่า…ฉันไม่แน่ใจว่าสิ่งเหล่านี้มีชื่อหรือไม่ ฉันรู้ว่าตัวแยกวิเคราะห์ Marpaมีความสามารถในเรื่องนี้ แต่ตัวแยกวิเคราะห์แบบ Earley หรือ GLR ใด ๆ ที่สามารถดึงออกได้

อย่างไรก็ตามคุณไม่ต้องการสิ่งใดเลย คุณมีสตรีมที่มีเอกสารแบบฝังหลายฉบับพร้อมขยะในระหว่าง:

 garbagegarbage{key:42}garbagegarbage[1,2,3]{id:0}garbage...

ดูเหมือนว่าคุณต้องการตัวแยกวิเคราะห์ที่ข้ามขยะและ (ขี้เกียจ) ให้ลำดับของ AST สำหรับแต่ละเอกสาร นี้อาจได้รับการพิจารณาให้เป็น parser ที่เพิ่มขึ้นในความรู้สึกทั่วไปมากที่สุด แต่คุณจะใช้วงแบบนี้จริง ๆ :

while stream is not empty:
  try:
    yield parse_document(stream at current position)
  except:
    advance position in stream by 1 character or token

parse_docmentฟังก์ชั่นนั้นจะเป็นแบบเดิม parser ไม่ใช่ที่เพิ่มขึ้น มีปัญหาเล็กน้อยในการทำให้แน่ใจว่าคุณได้อ่านสตรีมอินพุทเพียงพอสำหรับการวิเคราะห์คำที่ประสบความสำเร็จ วิธีการจัดการนี้จะขึ้นอยู่กับประเภทของเครื่องมือแยกวิเคราะห์ที่คุณใช้ ความเป็นไปได้รวมถึงการเพิ่มบัฟเฟอร์ในข้อผิดพลาดในการแยกวิเคราะห์บางส่วนหรือใช้โทเค็นขี้เกียจ

โทเค็น Lazy อาจเป็นโซลูชันที่หรูหราที่สุดเนื่องจากสตรีมอินพุตของคุณ แทนที่จะมีขั้นตอนการผลิต lexer รายการคงที่ของสัญญาณ parser จะเฉื่อยชาขอโทเค็นต่อไปจากการเรียกกลับ lexer [1] เล็กซ์เซอร์จะบริโภคสตรีมได้มากเท่าที่ต้องการ วิธีนี้ตัวแยกวิเคราะห์สามารถล้มเหลวเมื่อถึงจุดสิ้นสุดจริงของกระแสข้อมูลหรือเมื่อเกิดข้อผิดพลาดในการแยกวิเคราะห์จริง (เช่นเราเริ่มแยกวิเคราะห์ในขณะที่ยังอยู่ในถังขยะ)

^{[1] lexer โทรกลับที่ขับเคลื่อนด้วยความคิดที่ดีในบริบทอื่น ๆ เช่นกันเพราะสามารถหลีกเลี่ยงบางปัญหากับที่ยาวที่สุดโทเค็นการจับคู่}

หากคุณรู้ว่าคุณกำลังค้นหาเอกสารประเภทใดคุณสามารถเพิ่มประสิทธิภาพการข้ามเพื่อหยุดเฉพาะที่ที่สัญญาได้เท่านั้น เช่นเอกสาร JSON มักจะเริ่มต้นด้วยตัวอักษรหรือ{ [ดังนั้นขยะคือสตริงใด ๆ ที่ไม่มีอักขระเหล่านี้

ไม่มีชื่อเฉพาะสำหรับ parser ที่ทำสิ่งนี้ แต่ผมจะเน้นหนึ่งขั้นตอนวิธีการที่ไม่นี้: แยกที่มีอนุพันธ์

มันใช้อินพุตโทเค็นครั้งละหนึ่งตัว มันจะสร้างป่าแยกวิเคราะห์เมื่อสิ้นสุดอินพุต นอกจากนี้คุณยังสามารถรับทั้งป่าในการแยกวิเคราะห์ในขณะที่อยู่ในกลางของการแยกวิเคราะห์ ( แยกบางส่วน )

การแยกวิเคราะห์ด้วยอนุพันธ์จัดการกับไวยากรณ์ที่ไม่มีบริบทและจะสร้างป่าแยกสำหรับไวยากรณ์ที่ไม่ชัดเจน

มันเป็นทฤษฎีที่สง่างามจริง ๆ แต่อยู่ในช่วงวัยเด็กเท่านั้นและไม่ได้นำไปใช้อย่างกว้างขวาง Matt Might มีรายการลิงก์ไปยังการนำไปใช้งานต่าง ๆ ใน Scala / Racket / etc

ทฤษฎีนั้นง่ายต่อการเรียนรู้ถ้าคุณเริ่มต้นด้วยการจดจำด้วยอนุพันธ์ (นั่นคือเริ่มต้นด้วยการใช้อนุพันธ์ของภาษาโดยมีเป้าหมายในการรับรู้ข้อมูลบางอย่างเพื่อตรวจสอบว่ามันถูกต้องหรือไม่) แล้วปรับเปลี่ยนโปรแกรมเพื่อแยกวิเคราะห์อนุพันธ์ นั่นคือเปลี่ยนมันเพื่อแทนการซื้อขายสัญญาซื้อขายล่วงหน้าของภาษาก็จะใช้เวลาของอนุพันธ์ของparsersและคำนวณป่าแจงก)

ห่างไกลจากอุดมคติ แต่ฉันเห็นว่าทำไปแล้วมากกว่าหนึ่งครั้ง: ที่แต่ละบรรทัดอินพุตพยายามแยกวิเคราะห์ หากล้มเหลวให้รักษาบรรทัดและเพิ่มรายการถัดไป ใน pseudocode:

buffer = ''
for each line from input:
    buffer = buffer + line
    if can parse buffer:
        emit tree
        buffer = ''

ปัญหาใหญ่คือในบางภาษาคุณไม่สามารถทราบได้ว่านิพจน์นั้นเสร็จสมบูรณ์ก่อนที่จะอ่านบรรทัดถัดไปหรือไม่ ในกรณีนี้ดูเหมือนว่าคุณสามารถอ่านถัดไปและตรวจสอบว่ามันเป็นจุดเริ่มต้นที่ถูกต้องหรือต่อเนื่องที่ถูกต้อง ... แต่สำหรับที่คุณต้องการไวยากรณ์ภาษาที่แน่นอน

ที่แย่กว่านั้นในภาษาเหล่านั้นการสร้างกรณีทางพยาธิวิทยาที่ไม่สามารถแยกวิเคราะห์ได้จนกว่าจะสิ้นสุดไฟล์แม้ว่าจะไม่ใช่คำสั่งที่ยาวเพียงคำเดียวก็ตาม

โดยสังเขป

ดูเหมือนว่าวิธีแก้ปัญหาอย่างรวดเร็วของคุณคือการกำหนด REGEX หรือ FSA (สถานะออโตเมติก จำกัด ) ที่รับรู้จุดเริ่มต้นที่เป็นไปได้ทั้งหมดของเอกสาร (อนุญาตบวกเท็จซึ่งไม่ตรงกับเอกสาร) จากนั้นคุณสามารถเรียกใช้มันอย่างรวดเร็วในการป้อนข้อมูลของคุณเพื่อระบุสถานที่ต่อไปที่เอกสารอาจเริ่มต้นด้วยข้อผิดพลาดเล็กน้อย มันอาจทำให้เกิดตำแหน่งที่ผิดพลาดเล็กน้อยสำหรับการเริ่มต้นเอกสาร แต่ parser จะถูกจดจำและถูกละทิ้ง

ดังนั้นAutomite Stateอาจเป็นชื่อ parser ที่คุณต้องการ :)

ปัญหา

เป็นการยากที่จะเข้าใจปัญหาที่เกิดขึ้นจริงโดยเฉพาะเมื่อคำศัพท์อาจมีการตีความมากมาย คำว่าแจงป่าถูกประกาศเกียรติคุณ (afaik) สำหรับการแยกบริบทฟรี (CF) ของการแยกประโยคที่ไม่ชัดเจนที่มีต้นไม้แยกหลาย มันสามารถวางนัยทั่วไปในการแยกวิเคราะห์ประโยคของประโยคหรือไวยากรณ์ประเภทอื่น ๆ ดังนั้นคำตอบทั้งหมดเกี่ยวกับ Earley, GLR, Marpa และ parsers อนุพันธ์ (มีอื่น ๆ อีกมากมาย) ที่ไม่เกี่ยวข้องในกรณีนี้

แต่นั่นไม่ใช่สิ่งที่คุณมีอยู่ในใจ คุณต้องการแยกสตริงที่ไม่ซ้ำกันซึ่งเป็นลำดับของเอกสารที่ไม่คลุมเครือและรับการแยกวิเคราะห์ต้นไม้สำหรับแต่ละโครงสร้างหรือการแทนโครงสร้างบางประเภทเนื่องจากคุณไม่ได้พูดจริง ๆ ว่ามีการกำหนดไวยากรณ์ของเอกสารของคุณไว้ที่ใด มุมมองภาษาอย่างเป็นทางการ สิ่งที่คุณมีคืออัลกอริทึมและตารางที่จะทำการแยกวิเคราะห์เมื่อเริ่มต้นที่จุดเริ่มต้นของเอกสาร ดังนั้นไม่ว่าจะเป็น

ปัญหาที่แท้จริงคือสตรีมเอกสารของคุณมีขยะจำนวนมากที่แยกเอกสาร และดูเหมือนว่าความยากของคุณคือการสแกนขยะนี้เร็วพอ เทคนิคปัจจุบันของคุณคือการเริ่มต้นที่จุดเริ่มต้นและพยายามสแกนจากอักขระตัวแรกและข้ามไปที่การรีสตาร์ทที่อักขระตัวถัดไปทุกครั้งที่มันล้มเหลวจนกว่าคุณจะได้รับเอกสารทั้งหมด จากนั้นให้คุณระบุซ้ำจากตัวอักษรตัวแรกหลังจากเอกสารเพิ่งสแกน

ที่ยังเป็นวิธีการแก้ปัญหาโดย @amon ในส่วนที่สองของคำตอบของเขา

อาจไม่ใช่วิธีแก้ปัญหาที่รวดเร็วมาก (ฉันไม่มีวิธีทดสอบ) เนื่องจากไม่น่าเป็นไปได้ที่โค้ดของตัวแยกวิเคราะห์จะได้รับการปรับให้เหมาะกับการเริ่มต้นอย่างมีประสิทธิภาพมากในตอนต้นของเอกสาร ในการใช้งานปกติจะทำได้เพียงครั้งเดียวเท่านั้นดังนั้นจึงไม่ใช่จุดที่น่าสนใจจากมุมมองการปรับให้เหมาะสมที่สุด ดังนั้นความสุขปานกลางของคุณด้วยวิธีนี้จึงไม่น่าแปลกใจ

ดังนั้นสิ่งที่คุณต้องการจริงๆคืออัลกอริทึมที่สามารถค้นหาจุดเริ่มต้นของเอกสารที่ขึ้นต้นด้วยขยะจำนวนมากได้อย่างรวดเร็ว และคุณโชคดี: มีอัลกอริธึมดังกล่าวอยู่ และฉันแน่ใจว่าคุณรู้มันมันถูกเรียกว่าค้นหา REGEX

ทางออกที่ง่าย

สิ่งที่คุณต้องทำคือการวิเคราะห์ข้อมูลจำเพาะของเอกสารของคุณเพื่อค้นหาว่าเอกสารเหล่านี้เริ่มต้นอย่างไร ฉันไม่สามารถบอกคุณได้อย่างแน่นอนว่าฉันไม่แน่ใจว่าข้อกำหนดคุณลักษณะไวยากรณ์ของพวกเขาถูกจัดอย่างเป็นทางการอย่างไร อาจเป็นไปได้ว่าพวกเขาทั้งหมดเริ่มต้นด้วยคำบางคำจากรายการที่ จำกัด อาจผสมกับเครื่องหมายวรรคตอนหรือตัวเลข นั่นคือให้คุณตรวจสอบ

สิ่งที่คุณต้องทำคือการกำหนดสถานะ จำกัด อัตโนมัติ (FSA) หรือเทียบเท่าสำหรับโปรแกรมเมอร์ส่วนใหญ่นิพจน์ปกติ (REGEX) ที่สามารถรับรู้อักขระสองสามตัวแรกของเอกสาร: ยิ่งดี แต่ไม่จำเป็นต้องมาก ใหญ่ (เนื่องจากอาจต้องใช้เวลาและพื้นที่) สิ่งนี้ควรจะทำได้ง่าย ๆ จากข้อกำหนดของเอกสารของคุณและสามารถทำได้โดยอัตโนมัติด้วยโปรแกรมที่อ่านข้อกำหนดของเอกสารของคุณ

เมื่อคุณสร้าง regexp ของคุณแล้วคุณสามารถเรียกใช้บนสตรีมอินพุทของคุณเพื่อเริ่มต้นอย่างรวดเร็วจนถึงจุดเริ่มต้นของเอกสารแรกของคุณ (หรือถัดไป) ดังนี้:

ผมถือว่า:
- docstartเป็น regex ที่ตรงกับจุดเริ่มต้นของเอกสารทั้งหมดที่
- search(regex, stream)เป็นฟังก์ชั่นที่การค้นหาสำหรับย่อยที่ตรงกันstream regexเมื่อมันกลับมาสตรีมจะถูกลดลงเป็นสตรีมย่อยคำต่อท้ายโดยเริ่มต้นที่จุดเริ่มต้นของสตริงย่อยที่ตรงกันครั้งแรกหรือไปยังสตรีมที่ว่างเปล่าไม่พบข้อมูลที่ตรงกัน
- parse(stream)พยายามแยกวิเคราะห์เอกสารจากจุดเริ่มต้นของสตรีม (สิ่งที่เหลืออยู่) และส่งคืนแผนผังการแยกในรูปแบบใด ๆ หรือล้มเหลว เมื่อมันกลับมาสตรีมจะถูกลดลงเป็นสตรีมย่อยคำต่อท้ายเริ่มต้นที่ตำแหน่งทันทีหลังจากสิ้นสุดเอกสารที่แยกวิเคราะห์ มันเรียกข้อยกเว้นถ้าการแยกวิเคราะห์ล้มเหลว

forest = empty_forest
search(docstart, stream)
while stream is not empty:
  try:
    forest = forest + parse(stream)
  except
    remove first character from stream
  search(docstart, stream)

โปรดทราบว่าจำเป็นต้องลบอักขระตัวแรกเพื่อให้การค้นหาถัดไปจะไม่พบการจับคู่แบบเดียวกันอีก

แน่นอนว่าการย่อของสตรีมเป็นรูปภาพ อาจเป็นเพียงดัชนีในสตรีม

หมายเหตุสุดท้ายคือ regex ของคุณไม่จำเป็นต้องแม่นยำเกินไปตราบใดที่มันรับรู้จุดเริ่มต้นทั้งหมด ถ้ารู้จักสายอักขระที่ไม่สามารถเป็นจุดเริ่มต้นของเอกสารได้ในบางครั้ง (ค่าบวกเท็จ) ค่าปรับเพียงอย่างเดียวคือค่าใช้จ่ายของการเรียก parser ที่ไร้ประโยชน์

ดังนั้นอาจช่วยให้ regex ง่ายขึ้นหากมีประโยชน์

เกี่ยวกับความเป็นไปได้ของการแก้ปัญหาที่รวดเร็วขึ้น

วิธีแก้ปัญหาข้างต้นควรใช้งานได้ดีในกรณีส่วนใหญ่ อย่างไรก็ตามหากคุณมีไฟล์ขยะและเทราไบต์จำนวนมากในการประมวลผลอาจมีอัลกอริทึมอื่นที่ทำงานเร็วกว่า

ความคิดที่มาจากวิธีการค้นหาสตริงบอยเยอร์มัวร์ อัลกอริทึมนี้สามารถค้นหาสตรีมสำหรับสตริงเดี่ยวอย่างรวดเร็วที่สุดเพราะใช้การวิเคราะห์โครงสร้างของสตริงเพื่อข้ามการอ่านสตรีมส่วนใหญ่กระโดดข้ามเศษเล็กเศษน้อยโดยไม่ต้องมองแม้แต่พวกเขา มันเป็นอัลกอริทึมการค้นหาที่เร็วที่สุดสำหรับสตริงเดียว

ปัญหาที่ยากคือการปรับตัวเพื่อค้นหา regex แทนที่จะเป็นสายเดียวดูเหมือนว่าละเอียดอ่อนมากและอาจไม่ทำงานขึ้นอยู่กับคุณสมบัติของ regex ที่คุณกำลังพิจารณา ซึ่งอาจขึ้นอยู่กับไวยากรณ์ของเอกสารที่คุณกำลังวิเคราะห์คำ แต่อย่าเชื่อใจฉันมากเกินไปเพราะฉันไม่มีเวลาอ่านเอกสารที่ฉันพบอย่างระมัดระวัง

ฉันทิ้งคุณไว้กับตัวชี้หนึ่งหรือสองตัวที่ฉันพบในเว็บรวมถึงตัวชี้วัดที่ชัดเจนว่าเป็นรายงานการวิจัยแต่คุณควรพิจารณาสิ่งนี้ว่าเป็นการเก็งกำไรมากขึ้นอาจเป็นงานวิจัยเพื่อพิจารณาเฉพาะเมื่อคุณประสบปัญหาประสิทธิภาพการทำงานที่รุนแรง และอาจไม่มีโปรแกรมชั้นวางที่จะทำ

สิ่งที่คุณอธิบายสามารถอธิบายได้ว่าเป็น SAX กับ SOM

SAX - (Simple API สำหรับ XML) เป็นตัวแยกวิเคราะห์การเข้าถึงลำดับเหตุการณ์ API ที่พัฒนาโดยรายชื่อผู้รับจดหมาย XML-DEV สำหรับเอกสาร XML

SOM - (แบบจำลองวัตถุ XML Schema) เข้าถึงแบบสุ่มไปยังในการเป็นตัวแทนหน่วยความจำของไฟล์ XML

มีการใช้งานทั้งสองประเภทใน C # และ Java และอาจมีอีกมากมาย โดยปกติแล้ว XSD หรือ DTD จะเป็นตัวเลือก

ความสุขของ SAX คือมันเป็นโอเวอร์เฮดหน่วยความจำต่ำซึ่งเหมาะสำหรับไฟล์ XML ขนาดใหญ่ การแลกเปลี่ยนคือการเข้าถึงแบบสุ่มโดยใช้ SAX นั้นไม่มีอยู่จริงหรือช้าและแย่กว่านั้นเวลาในการพัฒนามักจะมากกว่า SOM ปัญหาที่ชัดเจนของ SOM คือความต้องการ RAM ขนาดใหญ่

คำตอบนี้ไม่สามารถใช้ได้กับทุกแพลตฟอร์มและทุกภาษา