How the Zomic Language is Parsed

Here are the major players in the Zomic processing chain. The process falls in two halves. The first part goes from bytes to an abstract syntax tree (AST). The bytes are parsed by ZomicParser, an ANTLR parser generated from zomic.g. The second part visits that AST to drive a virtual machine that effects changes on the core vZome model.

Note that the two halves can be separated in terms of when they occur. The AST produced by parsing can be held in memory and processed much later by some Visitor implementation.

Part 1:

• com.vzome.core.zomic.parser.Parser

  instantiates processing chain: ZomicParser -> ANTLRContentSupplier -> XML2AST parse method produces an AST,

• com.vzome.core.antlr.ANTLR2XML

  interface for “XML content” events produces by ZomicParser

• com.vzome.core.antlr.ANTLRContentSupplier

  implementation of ANTLR2XML that produces generic SAX events

• com.vzome.core.zomic.parser.XML2AST

  handles SAX events, produces the Zomic AST

• com.vzome.core.zomic.program.Anything, etc.

  AST classes, and Visitor interface for them

Part 2:

• com.vzome.core.zomic.Interpreter

  a Visitor implementation that passes events to a ZomicEventHandler

• com.vzome.core.render.ZomicEventHandler

  interface for the Zomic virtual machine abstraction

• com.vzome.core.render.AbstractZomicEventHandler

  base implementation of ZomicEventHandler, with two subclasses

• com.vzome.core.commands.ZomicVirtualMachine

  subclass of AbstractZomicEventHandler that drives model changes captured in a command

Adopting ANTLR 4.x:

We can drop com.vzome.core.antlr completely, no matter what else we do. I’m assuming we’ll follow the best practice, and avoid putting any actions into our grammar.

From there, we have basically two options, summarized as keeping or discarding the existing Zomic AST structure, in favor of the ANTLR-generated parse tree. Bear in mind that the parse tree can be “walked” by a generic walker that emits the Listener events.

First let’s talk about discarding the Zomic AST. In this scenario, we would implement a Listener that directly drove a ZomicEventHandler. I don’t favor this approach. A parse tree is different from an abstract syntax tree, and we would suffer a little without the abstraction layer. We would also lose the ZomicPolyhedronModelInterpreter, which extends the Interpreter class to produce ball and strut models used to render.

The other approach is to write a Listener that replaces XML2AST, generating the AST. We would thus continue to use the Interpreter class to drive the virtual machine from the AST. We would also retain the ability to pretty-print the AST (via the other Visitor implementation, not currently hooked up to anything). I favor this approach. All of “Part 2” above is retained as-is.