##############################################
 FhY AST Definition and Parse Tree Conversion
##############################################

.. contents::
   :local:

Hi! Welcome to our third *FhY* design blog post. You may view our previous blog post
:doc:`here <post_2024-04-05>`.

*****************
 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:

   #. Full Initial Implementation of the AST Nodes

      #. Core AST Structures

         #. Can be found in the `lang/ast` module

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

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

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

Design Decisions Made or Discussed During the Meeting:
======================================================

   #. 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
      <https://github.com/apache/tvm/blob/main/python/tvm/runtime/object.py#L49C1-L49C26>`_.

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

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

   #. 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.

   #. :ref:`Type Qualifiers <defining-type-qualifiers>`: currently define supported type
      qualifiers using an enumeration in our code

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

   #. 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
      <https://tvm.apache.org/2020/09/26/bring-your-own-datatypes#:~:text=The%20Bring%20Your%20Own%20Datatypes%20framework%20allows%20users%20to%20claim,alongside%20TVM's%20normal%20datatype%20facilities.>`_
      model.

.. _defining-type-qualifiers:

*******************************************
 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):
=================

   #. Finish AST conversion strategy to support all AST nodes
   #. Setup GitHub Actions for automated testing on the remote repository
   #. Type & label checking (AST Node Passes)
   #. Define and design IR tables
   #. Serialization of AST
   #. Multiple file compilation strategy

TODO (Back Logged):
===================

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

-  **Release Date**: Thursday April 11th 2024
-  **Last Updated**: Friday May 24th 2024
-  **Post Author(s)**: Jason C Del Rio