<div class="key-takeaways"><ul><li>คอมไพเลอร์และอินเทอร์พรีเตอร์ไม่ได้ทำงานเป็นโปรแกรมขนาดยักษ์ชิ้นเดียว แต่แบ่งเป็นขั้นตอนย่อย</li><li>เลกเซอร์ (Lexer) ทำหน้าที่อ่านซอร์สโค้ดและตัดแบ่งเป็นชิ้นส่วนความหมายเรียกว่าโทเค็น</li><li>พาร์เซอร์ (Parser) สร้างโครงสร้าง AST เพื่อกำหนดลำดับความสำคัญของเครื่องหมายและนิพจน์</li><li>อินเทอร์พรีเตอร์ประเมินค่า AST โดยตรง ขณะที่คอมไพเลอร์แปลง AST เป็นชุดคำสั่ง</li></ul></div>เวลาที่เราเขียนโค้ดสั้นๆ อย่างคำสั่งบวกเลขแล้วสั่งพิมพ์ผลลัพธ์ผ่านหน้าจอ ชวนให้รู้สึกว่าคอมพิวเตอร์น่าจะแค่อ่าน ทำความเข้าใจ แล้วก็รันโค้ดนั้นได้ทันที แต่ในความเป็นจริงแล้วคอมพิวเตอร์ไม่ได้เข้าใจซอร์สโค้ดในแบบที่เรามองเห็นตามธรรมชาติการทำงานของภาษาโปรแกรมจำเป็นต้องนำซอร์สโค้ดนั้นมาค่อยๆ แปลงสภาพทีละขั้นจนกลายเป็นรูปแบบที่ระบบสามารถนำไปใช้งานต่อได้ กระบวนการนี้ถือเป็นหนึ่งในส่วนที่น่าสนใจที่สุดเบื้องหลังการทำงานของภาษาโปรแกรม โดยที่เราไม่จำเป็นต้องมีความรู้ระดับสูงด้านทฤษฎีคอมไพเลอร์ก็สามารถทำความเข้าใจได้บริบทเพิ่มเติม: การมองระบบประมวลผลภาษาโปรแกรมในลักษณะท่อส่งข้อมูล (Pipeline) ช่วยให้การพัฒนาซอฟต์แวร์มีความยืดหยุ่นสูง หากแต่ละขั้นตอนทำงานแยกจากกันอย่างเด็ดขาด นักพัฒนาสามารถปรับปรุงตัวแปลภาษาหรือเพิ่มฟีเจอร์ใหม่ในขั้นตอนหนึ่งได้โดยไม่ต้องรื้อระบบทั้งหมดจุดเริ่มต้นที่มีประโยชน์คือการเลิกมองว่าคอมไพเลอร์หรืออินเทอร์พรีเตอร์เป็นโปรแกรมมหึมาโปรแกรมเดียว แต่ให้มองภาพขั้นตอนการทำงานตามลำดับดังนี้:<ul><li>ซอร์สโค้ด (Source Code)</li><li>เลกเซอร์ (Lexer)</li><li>โทเค็น (Tokens)</li><li>พาร์เซอร์ (Parser)</li><li>โครงสร้าง AST</li><li>อินเทอร์พรีเตอร์ หรือ คอมไพเลอร์</li></ul>แต่ละขั้นตอนจะรับข้อมูลเข้ามาทำการแปลงและส่งผลลัพธ์ต่อไปยังขั้นตอนถัดไป เมื่อเราสร้างโมเดลความคิดนี้ขึ้นมาได้ คอมไพเลอร์และอินเทอร์พรีเตอร์ก็จะไม่ใช่เรื่องลึกลับอีกต่อไป ลองมาติดตามโปรแกรมตัวอย่างขนาดจิ๋วตลอดบทความนี้:let x = 5 + 3 print(x)ในมุมมองของมนุษย์เราสามารถมองเห็นและเข้าใจความหมายได้ทันที แต่ระบบของภาษาโปรแกรมไม่สามารถอาศัยสัญชาตญาณแบบนั้นได้ จำเป็นต้องมีกระบวนการประมวลผลซอร์สโค้ดอย่างเป็นระบบระเบียบ<div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ms9jwt10_inline_1_f702bcb299.jpg" alt="code compilation pipeline flowchart" loading="lazy" />ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</div>ตัวเลกเซอร์ (Lexer) หรือที่บางครั้งเรียกว่าโทเค็นไนเซอร์ (Tokenizer) มีหน้าที่อ่านซอร์สโค้ดแล้วแตกย่อยออกเป็นชิ้นส่วนที่มีความหมายเรียกว่าโทเค็น เช่นตัวอักษรเฉพาะอย่างตัวเลขและเครื่องหมายคำนวณ เลกเซอร์จะแปลงข้อมูลเหล่านี้ให้มีประโยชน์มากขึ้น เช่น แปลงตัวเลขและเครื่องหมายบวกให้ระบุประเภทได้อย่างชัดเจนสิ่งสำคัญคือเลกเซอร์สนใจเรื่องการจดจำแพทเทิร์นเป็นหลัก เช่น คำสั่งคือคีย์เวิร์ด ตัวอักษรคือตัวระบุตัวตน ตัวเลขคือจำนวนเต็ม และเครื่องหมายคือโอเปอเรเตอร์ โดยมันไม่ต้องทำความเข้าใจความหมายทั้งหมดของโปรแกรม และมักจะข้ามช่องว่าง (Whitespace) ไป ทำให้ขั้นตอนถัดไปได้รับข้อมูลที่สะอาดกว่าเดิมแม้จะได้โทเค็นมาแล้วแต่ก็ยังเป็นเพียงลำดับข้อมูลแบบแบนๆ เท่านั้น คำถามสำคัญคือโครงสร้างของนิพจน์นั้นคืออะไรกันแน่ระหว่างการบวกก่อนคูณหรือคูณก่อนบวก ซึ่งพาร์เซอร์ (Parser) จะทำหน้าที่เข้ามาตอบคำถามนี้โดยการสร้างโครงสร้างที่เรียกว่า Abstract Syntax Tree หรือ AST ขึ้นมาเมื่อได้ AST มาแล้ว เราสามารถเดินหน้าไปได้หลายทิศทาง โดยอินเทอร์พรีเตอร์สามารถประเมินค่า AST ได้โดยตรงและให้ผลลัพธ์ออกมาทันที ในขณะที่คอมไพเลอร์สามารถแปลง AST ให้กลายเป็นอีกรูปแบบหนึ่งอย่างชุดคำสั่ง (Instructions) ได้เช่นกันที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/odingaval/from-source-code-to-execution-the-mental-model-behind-compilers-and-interpreters-45on" target="_blank" rel="noopener noreferrer">Dev.to</a>

<div class="key-takeaways"><ul><li>Compilers and interpreters are not massive monolithic programs but consist of distinct pipeline stages.</li><li>The lexer reads source code and breaks it down into meaningful pieces called tokens.</li><li>The parser constructs an Abstract Syntax Tree (AST) to resolve operator precedence and grouping.</li><li>An interpreter evaluates the AST directly, whereas a compiler translates the AST into instructions.</li></ul></div>When writing a small snippet of code that performs arithmetic and prints the result, it feels like the computer should simply read it, understand it, and execute it. However, computers do not naturally understand source code the way human beings do.A programming language implementation has to take that source code and progressively transform it into something it can actually work with. This process represents one of the most fascinating aspects of how programming languages function, and you do not need advanced compiler theory to grasp it.Context Note: Viewing language execution as a pipeline architecture provides immense software engineering benefits. By isolating each stage's responsibilities, language designers can modify or optimize individual components without disrupting the entire compilation or interpretation pipeline.A useful starting point is to stop thinking of a compiler or interpreter as one enormous program and instead view it through a sequential model:<ul><li>Source Code</li><li>Lexer</li><li>Tokens</li><li>Parser</li><li>AST</li><li>Interpreter / Compiler</li></ul>Each stage takes something in, transforms it, and hands the result directly to the next stage. Once this mental model clicks, compilers and interpreters become significantly less mysterious. Let us follow one tiny program throughout this article:let x = 5 + 3 print(x)As humans, we can look at this and immediately understand several things. The language implementation, on the other hand, cannot simply rely on intuition and must systematically process the source code.<div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ms9jwt10_inline_1_f702bcb299.jpg" alt="code compilation pipeline flowchart" loading="lazy" />Stock photo for illustration only, not from the actual event</div>The lexer, sometimes referred to as a tokenizer, is responsible for reading the raw source code and breaking it into meaningful pieces called tokens. It translates raw characters into structured tokens that specify data types, such as integers, identifiers, assignments, and operators.The important takeaway is that the lexer focuses primarily on recognizing patterns. It identifies keywords, identifiers, numbers, and operators without needing to understand the full semantic meaning of the program. Whitespace is usually skipped, ensuring the subsequent stage receives a much cleaner stream of information.Even after tokenization, the tokens remain a relatively flat sequence. A critical question remains regarding expression structure and operator precedence. The parser is responsible for answering this by taking the tokens and building a hierarchical representation known as an Abstract Syntax Tree (AST).Once an AST is established, execution can diverge down different paths. An interpreter can evaluate the AST directly to produce a final result, while a compiler can transform that same AST into a sequence of low-level machine or virtual instructions.Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/odingaval/from-source-code-to-execution-the-mental-model-behind-compilers-and-interpreters-45on" target="_blank" rel="noopener noreferrer">Dev.to</a>

medium_article-1104.png

small_article-1104.png

thumbnail_article-1104.png

Inewgen

Inewgen

#Interpreter

From Source Code to Execution: The Mental Model Behind Compilers and Interpreters

Inewgen