ตัวอย่างที่ง่ายที่สุดในการอธิบายความแตกต่างระหว่าง Parse Trees กับ Abstract Syntax Trees คืออะไร


14

เพื่อความเข้าใจของฉัน parser สร้างต้นไม้แยกวิเคราะห์แล้วทิ้งหลังจากนั้น อย่างไรก็ตามมันยังสามารถโผล่ออกมาจากต้นไม้ไวยากรณ์นามธรรมซึ่งคอมไพเลอร์ควรจะใช้

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


3
ทำไมพวกเขาต้องแตกต่างกัน พวกเขาไม่สามารถเป็นสิ่งเดียวกันจากมุมมองที่ต่างกันสองจุดได้หรือไม่
S.Lott

1
ไม่แน่ใจว่าฉันเข้าใจทั้งสอง "มุมมองที่แตกต่างกันเล็กน้อย" :-(
Combinator Logic

นั่นคือประเด็น พวกเขาเป็นสิ่งเดียวกันดังนั้นความสับสน คุณมีคำที่แตกต่างกันขึ้นอยู่กับมุมมองของคุณ: การแยกกับการสร้างรหัส (หรือการดำเนินการในกรณีของล่าม)
S.Lott

ไม่มีความแตกต่าง ด้วยจินตนาการเพียงเล็กน้อยเราสามารถประดิษฐ์การแสดงไวยากรณ์สำหรับแผนผังไวยากรณ์นามธรรมที่เป็นไปได้ ด้วยการขาดจินตนาการ S-expressions ของ Lisp จะเป็นไวยากรณ์เริ่มต้นที่เหมาะสมสำหรับทุกสิ่ง
SK-logic

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

คำตอบ:


20

ต้นไม้แจงเป็นที่รู้จักกันว่าต้นไม้ไวยากรณ์ที่เป็นรูปธรรม

โดยทั่วไปต้นไม้นามธรรมมีข้อมูลน้อยกว่าต้นไม้คอนกรีต ต้นไม้คอนกรีตมีองค์ประกอบแต่ละส่วนในภาษาในขณะที่ต้นไม้นามธรรมได้โยนชิ้นส่วนที่ไม่น่าสนใจออกไป

ตัวอย่างเช่นการแสดงออก: (2 + 5) * 8

คอนกรีตมีลักษณะเช่นนี้

  ( 2  + 5 )  * 8
  |  \ | / |  | |
  |   \|/  |  | |
   \___|__/   | |
       \______|/

ในขณะที่ต้นไม้นามธรรมมี:

2  5 
 \/   
  +  8
   \/
   *

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


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

1
@Ingo ไม่มีอะไรในคำตอบของฉันมีอะไรจะพูดเกี่ยวกับเมื่อคอมไพเลอร์ทิ้งวงเล็บ มันถามว่าอะไรคือความแตกต่างระหว่างต้นไม้แจงคอนกรีตและต้นไม้แยกวิเคราะห์นามธรรม
Winston Ewert

ดังนั้นแน่นอนคุณสามารถตั้งชื่อแหล่งที่มาสำหรับการเรียกร้องของคุณ? หรือนี่เป็นเพียงคำจำกัดความส่วนตัวของคุณ?
Ingo

1
@Ingo, en.wikipedia.org/wiki/Abstract_syntax_treeและen.wikipedia.org/wiki/Concrete_syntax_tree
Winston Ewert


0

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

ตัวอย่างเช่นภาษาต่อไปนี้:

prog:
      definition 
    | definition ';' prog
    ;

definition: .....

สามารถแสดงเป็นรายการของคำจำกัดความ (Nitpickers จะชี้ให้เห็นว่ารายการนั้นเป็นต้นไม้ที่เสื่อมโทรมแต่ทว่า)

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

parser :: String             -> Maybe [Definitions]      -- parser
pass1  :: [Definitions]      -> Maybe DesugaredProg      -- desugarer
pass2  :: DesugaredProg      -> Maybe TypedProg          -- type checker
pass3  :: TypedProg          -> Maybe AbstractTargetLang -- code generation
pass4  :: AbstractTargetLang -> Maybe String             -- pretty printer

compiler :: String           -> Maybe String    -- transform source code to target code
compiler source = do
   defs  <- parser source
   desug <- pass1 defs
   typed <- pass2 desug
   targt <- pass3 typed
   pass4 targt

บรรทัดด้านล่าง: ถ้าคุณได้ยินคนพูดคุยเกี่ยวกับต้นไม้แยก , ต้นไม้ syntac นามธรรม , ต้นไม้ไวยากรณ์คอนกรีตฯลฯ มักจะใช้แทนโดยโครงสร้างข้อมูลที่เหมาะสมสำหรับวัตถุประสงค์ที่กำหนดและคุณกำลังดี


2
นี่เป็นคำตอบของคำถามได้อย่างไร
Winston Ewert

@ WinstonEwert ฉันอ้างว่า "parse tree" และ "abstract syntax tree" เป็น abstractions และไม่มีความหมายอะไรมากไปกว่า "โครงสร้างข้อมูลที่เหมาะสม" ดังนั้นคำตอบคือว่าคำถามในทั่วๆไปมันไม่ได้ทำให้ความรู้สึกเว้นแต่คุณขอความแตกต่างระหว่างประเภทการกลับมาของตัวแยกวิเคราะห์และประเภทของการกลับมาของบางส่วนผ่านคนอื่น ๆ ใน XY คอมไพเลอร์ของภาษาลิตร
Ingo
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.