Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Build Your Own Programming Language

You're reading from   Build Your Own Programming Language A programmer's guide to designing compilers, interpreters, and DSLs for solving modern computing problems

Arrow left icon
Product type Paperback
Published in Dec 2021
Publisher Packt
ISBN-13 9781800204805
Length 494 pages
Edition 1st Edition
Arrow right icon
Author (1):
Arrow left icon
Clinton  L. Jeffery Clinton L. Jeffery
Author Profile Icon Clinton L. Jeffery
Clinton L. Jeffery
Arrow right icon
View More author details
Toc

Table of Contents (25) Chapters Close

Preface 1. Section 1: Programming Language Frontends
2. Chapter 1: Why Build Another Programming Language? FREE CHAPTER 3. Chapter 2: Programming Language Design 4. Chapter 3: Scanning Source Code 5. Chapter 4: Parsing 6. Chapter 5: Syntax Trees 7. Section 2: Syntax Tree Traversals
8. Chapter 6: Symbol Tables 9. Chapter 7: Checking Base Types 10. Chapter 8: Checking Types on Arrays, Method Calls, and Structure Accesses 11. Chapter 9: Intermediate Code Generation 12. Chapter 10: Syntax Coloring in an IDE 13. Section 3: Code Generation and Runtime Systems
14. Chapter 11: Bytecode Interpreters 15. Chapter 12: Generating Bytecode 16. Chapter 13: Native Code Generation 17. Chapter 14: Implementing Operators and Built-In Functions 18. Chapter 15: Domain Control Structures 19. Chapter 16: Garbage Collection 20. Chapter 17: Final Thoughts 21. Section 4: Appendix
22. Assessments 23. Other Books You May Enjoy Appendix: Unicon Essentials

Knowing when you need a new control structure

You need a new control structure when it addresses one or more major programming pain points. Often, pain points arise when people start writing software in support of a new class of computer hardware, or for a new application domain. Awareness or knowledge of an application domain's pain points may or may not exist at language design time, but more often, the awareness of pain points is generated from early substantial experiences attempting to write software for that domain.

Pain points are often due to complexity, frequent and pernicious bugs, code duplication, or several other famous bad smells or antipatterns. Some code smells are described in Refactoring: Improving the Design of Existing Code, by Martin Fowler. Antipatterns are described at antipatterns.com and in several books referenced on that site.

Individual programmers or programming projects may be able to reduce their code smells or avoid antipatterns by performing...

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image