FhY AST Definition and Parse Tree Conversion#

Hi! Welcome to our third FhY design blog post. You may view our previous blog post here.

Meeting Minutes#

We met on Wednesday April 10th, 2024 and had the following discussions:

Current Progress:#

Today we reviewed our current progress on development of FhY, as follows:

  1. Full Initial Implementation of the AST Nodes

    1. Core AST Structures

      1. Can be found in the lang/ast module

  2. Conversion of concrete syntax parse tree to AST through an ANTLR-generated visitor subclass

    1. Current status: in progress; not all AST nodes are supported by converter

  3. Simple unit testing paradigms for test-driven development (TDD)

Design Decisions Made or Discussed During the Meeting:#

  1. Regarding AST nodes: keep the classes light (i.e., not inheriting from third-party graph library). All nodes are children of the class Node, which is just a Python abstract base class. We observe the same design paradigm from TVM.

  2. Visualization: need more visualization tools, so need to consider supporting GraphViz (dot language)

    1. Currently considering a graph library that can support visualization and graphviz

  3. Serialization: we need to construct methods to serialize the AST representation, and all subsequent data structures for easier debugging purposes; should support a json.dump-like interface which can accept an indent such that when we traverse subsequent child nodes, the depth of the current position correctly indents the serialized data representation output.

  4. Type Qualifiers: currently define supported type qualifiers using an enumeration in our code

    1. Small Note: currently only support a single type qualifier but will need to support a series of type qualifiers in the future

  5. Type Registration: lightly touched on the subject of registering new data types and type qualifiers; will need a reliable way for users to register new type definitions, much like the Bring Your Own DataType model.

Where to Define Supported Type Qualifiers#

Currently, the FhY grammar does not define type qualifier keywords but instead will grab any IDENTIFIER token. Instead, we define supported type qualifiers (keywords) using an enumeration in our code. The rationale behind this choice is this: our code raises syntax errors, not the parser generator, ANTLR. For this reason, we will define our supported type qualifiers in our code.

TODO (immediate):#

  1. Finish AST conversion strategy to support all AST nodes

  2. Setup GitHub Actions for automated testing on the remote repository

  3. Type & label checking (AST Node Passes)

  4. Define and design IR tables

  5. Serialization of AST

  6. Multiple file compilation strategy

TODO (Back Logged):#

  1. Design and implementation of new type (and type qualifier) registration by users

  2. Design of IR

  • Release Date: Thursday April 11th 2024

  • Last Updated: Friday May 24th 2024

  • Post Author(s): Jason C Del Rio