concept ast in category dsl

This is an excerpt from Manning's book Domain-Specific Languages Made Easy MEAP V02. Login to get full access to this book.

In section 2.1, we’ll learn how to write down structured data precisely in the form of so-called object-relation diagrams. This notation is also used throughout the rest of the book to graphically represent DSL content in its so-called abstract syntax. in section 2.2, we’ll extract such diagrams from example DSL content. This extraction process works generically for all notated DSL content to produce so-called Abstract Syntax Trees (ASTs). In chapter 4, we’ll reverse this process: given an AST represented in code, reconstruct the notated DSL content - also known as concrete syntax. The visualizer we’ll implement for this will be the basis for the DSL editor. In chapter 5, we’ll make this visualization editable.

In the previous chapter you learned what an AST is, and how to represent one using an object-relation diagram. In this chapter, you’ll learn how to put this representation into code, as in-memory data, and to “work with” that encoded AST: inspect it, alter it, and traverse it. These skills will form the basis of the Domain IDE’s code base. You’ll probably also encounter these notions more generally outside of this book.

Figure 3.8. Encoding an AST generically.

This is an excerpt from Manning's book DSLs in Action. Login to get full access to this book.

Syntax tree manipulation is yet another option that’s used for implementing internal DSLs. The design follows the interpreter pattern (see [1] in section 2.6) and uses the infrastructure of the host language to create and manipulate the abstract syntax tree (AST) of the language. After you’ve generated the AST, it’s your responsibility to traverse the AST and do the manipulations that will generate the necessary code for the domain logic. Groovy and Ruby have developed this infrastructure through library support that can generate code by manipulating the AST.

Come to think of it, this is what Lisp offers you out of the box with its language infrastructure. In Lisp, every program is a list structure, which is the AST that the programmer has access to. Manipulating the AST to generate code is the basis of the Lisp macros. You can extend the core language syntax by manipulating the AST.

Figure 7.2. The simplest form of an external DSL. The parsing infrastructure does everything necessary to produce the target actions. The phases of processing the DSL script (lexicalization, parsing, generating the AST, and code generation) are all bundled in one monolithic block.

Any left-recursive rule can be converted to an equivalent non-left recursive one through a process of transformation. Some packrat parsers can do this for directly left-recursive rules. But transforming the rules makes them more obscure to the reader and makes the process of generating an AST more complex.

Listing 8.5. Semantic model for the order-processing DSL

package trading.dsl object AST { trait PriceType case object MIN extends PriceType case object MAX extends PriceType case class PriceSpec(pt: Option[PriceType], price: Int) case class SecuritySpec(qty: Int, security: String) trait BuySell case object BUY extends BuySell case object SELL extends BuySell case class LineItem(ss: SecuritySpec, bs: BuySell, ps: PriceSpec) case class Items(lis: Seq[LineItem]) case class AccountSpec(account: String) case class Order(items: Items, as: AccountSpec) }

copy